Что означает «sh a.sh <& 0> & 0»?

sh a.sh <&0 >&0 – что это значит? В частности, я не совсем понимаю, что означает &0 .

& с цифрой в этом случае указывает номер файла. Номер файла 0 – стандартный ввод ( stdin ). Символы < и > указывают на перенаправление стандартного и стандартного процесса процесса соответственно.

Итак, короче говоря, эта команда означает запуск a.sh in sh (как сценарий оболочки), перенаправление стандартного и стандартного скрипта (на самом деле, подоболочки) стандартным.

В этом случае <&0 избыточно (это поведение по умолчанию). >&0 будет означать, что он печатает то, что в противном случае было бы напечатано на стандартном стандарте вместо этого, относительно родительской оболочки. Большинство ttys будут эхо-сигнала такого вывода, и поэтому в результате перенаправление практически не влияет и, вероятно, не имеет видимого эффекта.

В одном случае это было бы разумно, если бы стандартный выходной файл родительской оболочки был странно закрыт. Это странный крайний случай.

n>&p и n<&p являются одним и тем же оператором и предназначены для дублирования файлового дескриптора (fd) p в дескрипторе файла n . Или, наоборот, они перенаправляют дескриптор файла n на любой ресурс, на который перенаправляется fd p .

Элементы < и > не используются для определения того, в каком направлении (чтение или запись) будет использоваться перенаправленный файловый дескриптор. n будет иметь такое же направление, как p . То есть, если p был открыт для записи, то будет и n даже если используется оператор n<&p .

Единственное различие между двумя операторами – это когда n не указано. >&p перенаправляет stdout (это как 1>&p или 1<&p ), а <&p перенаправляет stdin (как 0<&p или 0>&p ).

Таким образом, <&0 похоже на 0<&0 , поэтому перенаправляет stdin на любой ресурс, на который был перенаправлен stdin, так что ничего полезного, это не-op и не имеет большого смысла.

>&0 дублирует fd 0 на fd 1. Поскольку fd 1 (stdout), по умолчанию используется только для записи, что >&0 имеет смысл только в том случае, если fd 0 был открыт в режиме чтения + записи.

Это будет иметь место в случаях, когда fd 0 указывает на терминальное устройство, поскольку терминальные эмуляторы или getty обычно открывают терминальное устройство в режиме чтения + записи и присваивают ему fds 0, 1 и 2.

Поэтому, возможно, тот, кто писал, хотел перенаправить stdout на терминал, предполагая, что stdin указывает на него.

Единственное место, где имеет смысл n>&n – это zsh и функция mult_IOs . В zsh :

 some-cmd >&1 > some-file # that is: some-cmd 1>&1 1> some-file 

Перенаправляет стандартный вывод some-cmd на оба значения stdout: (& 1) и some-file , как если бы вы написали:

 some-cmd | tee some-file 

В то время как

 some-cmd <&0 < some-file # that is: some-cmd 0<&0 0< some-file 

сначала some-file бы оригинальный stdin, а затем some-file качестве ввода some-cmd как если бы вы написали:

 cat - some-file | some-cmd 

Но в cmd <&0 >&0 , fd 0 перенаправляется только один раз, поэтому это не применяется.