> & - более эффективен, чем> / dev / null?

Вчера я прочитал этот комментарий, который говорит, что в оболочке (по крайней мере bash) >&-"имеет тот же результат, что и" >/dev/null.

Этот комментарий фактически ссылается на руководство АБС как на источник информации. Но этот источник говорит, что >&-синтаксис «закрывает файловые дескрипторы».

Мне не ясно, являются ли два действия закрытия файлового дескриптора и перенаправления его на нулевое устройство полностью эквивалентными. Итак, мой вопрос: они?

На первый взгляд кажется, что закрытие дескриптора похоже на закрытие двери, но перенаправление его на нулевое устройство открывает дверь в подвешенное состояние! Эти две вещи не кажутся мне абсолютно одинаковыми, потому что, если я увижу закрытую дверь, я не буду пытаться выбросить из нее что-либо, но если я увижу открытую дверь, то предположу, что смогу.

Другими словами, я всегда задавался вопросом, >/dev/nullозначает ли это средство, cat mybigfile >/dev/nullкоторое фактически обрабатывает каждый байт файла и записывает его в тот, /dev/nullкоторый его забывает. С другой стороны, если оболочка встречает закрытый файловый дескриптор, я склонен думать (но не уверен), что она просто ничего не будет писать, хотя остается вопрос, catбудет ли по- прежнему считываться каждый байт.

Этот комментарий говорит >&-и >/dev/null« должен » быть таким же, но это не настолько громкий ответ для меня. Я хотел бы получить более авторитетный ответ со ссылкой на стандарт или ядро ​​источника или нет ...

Нет, вы определенно не хотите закрывать файловые дескрипторы 0, 1 и 2.

Если вы сделаете это, то в первый раз, когда приложение откроет файл, оно станет stdin / stdout / stderr ...

Например, если вы делаете:

echo text | tee file >&-

Когда tee(по крайней мере, некоторые реализации, такие как busybox ') откроет файл для записи, он будет открыт в файловом дескрипторе 1 (stdout). Так teeнапишу textдважды в file:

$ echo text | strace tee file >&-
[...]
open("file", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 1
read(0, "text\n", 8193)                 = 5
write(1, "text\n", 5)                   = 5
write(1, "text\n", 5)                   = 5
read(0, "", 8193)                       = 0
exit_group(0)                           = ?

Известно, что это вызывает уязвимости в безопасности. Например:

chsh 2>&-

И chsh(приложение setuid) может в конечном итоге писать сообщения об ошибках в /etc/passwd.

Некоторые инструменты и даже некоторые библиотеки пытаются защититься от этого. Например, GNU teeпереместит файловый дескриптор на один выше 2, если файлы, которые он открывает для записи, назначены 0, 1, 2, а busybox teeнет.

Большинство инструментов, если они не могут записать в stdout (потому что, например, он не открыт), сообщат об ошибке на stderr (на языке пользователя, что означает дополнительную обработку для открытия и анализа файлов локализации ...), поэтому это будет значительно менее эффективно и, возможно, приведет к сбою программы.

В любом случае, это не будет более эффективным. Программа по-прежнему будет выполнять write()системный вызов. Это может быть более эффективным, только если программа прекращает запись в stdout / stderr после первого сбоя write()системного вызова, но программы обычно этого не делают. Обычно они либо выходят с ошибкой, либо продолжают попытки.

Я всегда задавался вопросом, >/dev/nullозначает ли это, cat mybigfile >/dev/nullчто фактически обрабатывает каждый байт файла и записывает его, /dev/nullкоторый его забывает.

Это не полный ответ на ваш вопрос, но да, выше, как это работает.

catчитает именованные файлы или стандартный ввод, если файлы не названы, и выводит на свой стандартный вывод их содержимое до тех пор, пока он не встретит EOF на (включая стандартный ввод) последнем названном файле. Это его работа.

Добавляя, >/dev/nullвы перенаправляете стандартный вывод в / dev / null. Это специальный файл (узел устройства), который выбрасывает все, что в нем записано (и сразу возвращает EOF при чтении). Обратите внимание, что перенаправление ввода-вывода - это функция, предоставляемая оболочкой, а не каждым отдельным приложением, и что в имени / dev / null нет ничего волшебного , только то, что происходит в большинстве Unix-подобных систем .

Также важно отметить, что конкретная механика узлов устройств варьируется от операционной системы к операционной системе, но cat (что в системе GNU означает coreutils) является кроссплатформенной (один и тот же исходный код должен работать как минимум в Linux и Hurd) и, следовательно, не может принимать зависимости от конкретных ядер операционной системы. Кроме того, он все еще работает, если вы создаете псевдоним / dev / null (в Linux это означает узел устройства с тем же основным / второстепенным номером устройства) с другим именем. И всегда есть случай написания где-нибудь еще, который ведет себя практически одинаково (скажем, / dev / zero).

Из этого следует, что catон не знает о специальных свойствах / dev / null и, скорее всего, в первую очередь не знает о перенаправлении, но ему все равно необходимо выполнить точно такую ​​же работу: он читает именованные файлы и выводит содержимое / те файл (ы) к его стандартному выводу. То, что стандартный вывод catсобытия попадает в пустоту, catсамо по себе не касается.