cat < fileпечатает содержимое файла на стандартный вывод
cat > fileчитает стандартный ввод до тех пор, пока не будет обнаружен знак Ctrl+, Dа введенный текст записывается в файл .
cat <> fileпо крайней мере в моей версии Bash, печатает содержимое файла счастливо (без ошибок), но не изменяет файл и не обновляет метку времени изменения.
Как стандарт Bash оправдывает кажущееся игнорирование >в третьем утверждении - и, что более важно, он что- то делает ?
Ответы:
Bash использует <>для создания дескриптора файла для чтения и записи :
Оператор перенаправления
[n]<>wordприводит к открытию файла, имя которого является расширением слова, для чтения и записи в файловом дескрипторе n или в файловом дескрипторе 0, если n не указано. Если файл не существует, он создается.
cat <> fileоткрывает fileчтение-запись и привязывает его к дескриптору 0 (стандартный ввод). По сути, это эквивалентно < fileлюбой разумно написанной программе, поскольку никто, скорее всего, не попытается записать в стандартный ввод, но если бы он это сделал, он смог бы.
Вы можете написать простую программу C , чтобы проверить , что непосредственно - write(0, "hello", 6)запишет helloв fileчерез стандартный ввод.
<>также должен работать в любой другой POSIX-совместимой оболочке с тем же эффектом.
4<>file) полезно, и я полагаю, что значение 0 по умолчанию так же хорошо, как и любое, когда вы его опускаете. Чтение со стандартного выхода не лучше.
<>В некоторых системах (например, в Linux) также полезно открывать именованные каналы без блокировки, пока другой процесс не откроет их для записи.
<>Оператор может быть полезен при написании приложения, которое работает с несколькими терминалами, и иногда хочет запустить оболочку. Эта оболочка, в свою очередь, не сможет запускать приложения, которые запускаются с обычного управляющего терминала, если она не сможет использовать <>... такой как ... пейджер more, который читает из стандартной ошибки, чтобы получить свои команды, поэтому стандартный ввод и стандартный вывод оба доступны для их обычного использования. cat food | more - >/dev/tty03 2<>/dev/tty03
<> fileоткрывает файл (на файловый дескриптор 0 (стандартного ввода) по умолчанию, как <) в чтение + запись режиме без усечения и создания файла , если он не существует заранее .
Это соответствует O_RDWR|O_CREATфлагам, переданным open()системному вызову. В отличие от этого <есть O_RDONLYи >есть O_WRONLY|O_CREAT|O_TRUNCи >> O_WRONLY|O_CREAT|O_APPEND.
Возможность записи в stdin не часто полезна, поскольку приложения обычно не пишут в их stdin. Приложения обычно не ожидают чтения и записи в файловом дескрипторе, который они получают при запуске; они обычно читают из stdin (или файлового дескриптора, который они открывают сами) и записывают в stdout или stderr (или файловый дескриптор, который они открывают сами).
<> может иметь свое использование:
cat <> fileболее, cat < fileесли вы не хотите, чтобы команда потерпела неудачу, если fileона не существует, а fileвместо этого создана пустая .Не усеченный аспект <>делает полезным перезаписывать файлы на месте. Однако в этом случае вы обычно не используете его в дескрипторе файла 0:
printf xxx 1<> fileзаменяет первые 3 байта fileс xxx.
В некоторых системах, таких как Linux, <>в именованном канале (FIFO) открывает именованный канал без блокировки (не дожидаясь, пока какой-либо другой процесс откроет другой конец), и обеспечивает сохранение структуры канала. Например, в:
mkfifo pipe; sed 's/foo/bar/g' <> pipesedобрабатывает входящие данные из любого числа других процессов, записывающих в него, и никогда не видит eof.
<>умолчанию используется 1<>(stdout) вместо 0<>(stdin). Это ошибка соответствия POSIX, о которой я сообщил, и она будет исправлена в следующем выпуске. github.com/att/ast/issues/75 Но до тех пор, пока текущие версии ksh93 не выйдут из употребления, вы должны включить номер дескриптора файла, чтобы использовать его <>переносимо.
mkfifo fifo; exec 3<>fifoблокировать?