Что именно означает & в перенаправлении вывода?
Я вижу такие вещи, как command 1> out
или с 2>&1
перенаправить stderr, но иногда я также вижу &>
само собой и т. д.
Каков наилучший способ понять &
и что это значит именно?
3 ответа
&
в 2>&1
просто говорит, что число 1
это дескриптор файла, а не имя файла. В этом случае standard output file descriptor
,
Если вы используете 2>1
то это перенаправит ошибки в файл с именем 1
но если вы используете 2>&1
то он отправит его standard output stream
,
это &>
говорит отправить оба, standard output
а также standard error
, где-то. Например, ls <non-existent_file> &> out.file
, Позвольте мне проиллюстрировать это на примере.
Настроить:
Создать файл
koko
со следующим содержанием:#!bin/bash ls j1 echo "koko2"
Сделайте его исполняемым:
chmod u+x koko
Теперь обратите внимание, что
j1
не существуетТеперь беги
./koko &> output
бежать
cat output
и ты увидишьls: cannot access 'j1': No such file or directory koko2
И то и другое, standard error
(ls: cannot access 'j1': No such file or directory
) а также standard output
(koko2
), были отправлены в файл output
,
Теперь запустите его снова, но на этот раз так:
./koko > output
Делать cat output
и вы увидите только koko2
лайк. Но не ошибка вывода из ls j1
команда. Это будет отправлено standard error
который вы увидите в своем терминале.
Важное замечание благодаря @Byte Commander:
Обратите внимание, что в command >file 2>&1
порядок перенаправления важен. Если ты пишешь command 2>&1 >file
вместо этого (что обычно не то, что вы хотите), он сначала перенаправит команду stdout
в файл и после этого перенаправить команду stderr
его сейчас не используется stdout
, так что он будет отображаться в терминале, и вы можете передать его или перенаправить снова, но он не будет записан в файл.
> FILE 2>&1
а также &> FILE
эквивалентны. См. 8.2.3.2. Перенаправление ошибок в Bash Guide для начинающих Глава 8
[n]>&word
называется Дублирующим дескриптором выходного файла (см. раздел 2.7.6 стандарта языка оболочки POSIX). Это специфическое поведение является особенностью борноподобных оболочек, в том числе ksh
, dash
, а также bash
; на самом деле, стандарт основан на оболочке Bourne и ksh
, Что касается руководств по tcsh и csh, то они, по-видимому, не предоставляют возможности дублирования файловых дескрипторов, однако из описания >&
, это ведет себя как &>
в bash
(то есть перенаправляет ошибки и нормальный вывод в файл).
В *nix-подобных системах, включая Ubuntu, вы часто слышите, что все является файловым или, скорее, файловым дескриптором. Стандартный вывод - это константный дескриптор файла 1, а стандартная ошибка - дескриптор файла 2. Итак, > FILE 2>&1
технически означает дублирование файлового дескриптора 2 на файловый дескриптор 1. Другими словами, этот ответ:
2>&1 говорит оболочке дать команде дескриптор файла 2, который является дубликатом дескриптора 1. (т. Е. Stderr & stdout указывают на тот же fd).
Ключевым моментом здесь является то, что дескриптор 1 должен быть установлен первым. Поскольку оболочка обрабатывает перенаправления в порядке слева направо, command >FILE 2>&1
говорит оболочке перемонтировать stdout для command
идти в FILE
сначала и только потом дескриптор 2 может стать копией 1, то есть 1 и 2 указывают на одно и то же местоположение - FILE
,
Это, конечно, выходит за рамки стандартной ошибки и стандартного вывода. Как показывают в этом ответе, делая 3&>2
... вы дублируете (dup2) filedescritor 2 на filedescriptor 3, возможно закрывая filedescriptor 3, если он уже открыт
Примером манипулирования файловыми дескрипторами, среди многих, будет захват вывода dialog
команда в переменную
Стоит также отметить, что &>
специфично для bash
, В zsh
это ведет себя так же, но, согласно документации, "... не имеет такого же эффекта, как '> слово 2>&1' при наличии multios". В соответствии с POSIX /bin/sh
, это будет рассматриваться как обычное перенаправление с переводом команды в фоновый режим. Смотрите также, есть ли какой-нибудь sh-код, который не является синтаксически верным bash-кодом?,
Смотрите также: