Что в оболочке означает 2 ›и 1?

Дескриптор файла 1 - это стандартный вывод (stdout).
Дескриптор файла 2 - это стандартная ошибка (stderr).

Вот один из способов запомнить эту конструкцию (хотя он не совсем точен): сначала 2>1 может показаться хорошим способом перенаправить stderr на stdout. Однако на самом деле это будет интерпретироваться как перенаправление stderr в файл с именем 1. & указывает, что то, что следует и предшествует, является дескриптором файла, а не именем файла. Таким образом, конструкция становится: 2>&1.

Считайте >& оператором слияния с перенаправлением.

echo test > afile.txt

перенаправляет стандартный вывод на afile.txt. Это то же самое, что и делать

echo test 1> afile.txt

Чтобы перенаправить stderr, вы:

echo test 2> afile.txt

>& - это синтаксис для перенаправления потока на другой дескриптор файла: 0 - это стандартный ввод, 1 - стандартный вывод и 2 - стандартный поток.

Вы можете перенаправить stdout на stderr, выполнив:

echo test 1>&2 # or echo test >&2

Или наоборот:

echo test 2>&1

Итак, вкратце ... 2> перенаправляет stderr в (неуказанный) файл, добавление &1 перенаправляет stderr в stdout.

Некоторые хитрости с перенаправлением

Некоторые особенности синтаксиса могут иметь важные особенности. Вот несколько примеров переадресации, STDERR, STDOUT и порядка аргументов.

1 - перезапись или добавление?

Символ > означает перенаправление.

• > означает отправить в весь завершенный файл, перезаписывая целевой объект, если он существует (см. noclobber функцию bash в №3 позже).
• >> означает, что отправить в дополнение к будет добавляться к цели, если она существует.

В любом случае файл будет создан, если они не существуют.

2 - Командная строка оболочки зависит от порядка !!

Для тестирования нам нужна простая команда, которая будет отправлять что-то на оба выхода:

$ ls -ld /tmp /tnt
ls: cannot access /tnt: No such file or directory
drwxrwxrwt 118 root root 196608 Jan  7 11:49 /tmp

$ ls -ld /tmp /tnt >/dev/null
ls: cannot access /tnt: No such file or directory

$ ls -ld /tmp /tnt 2>/dev/null
drwxrwxrwt 118 root root 196608 Jan  7 11:49 /tmp

(Конечно, ожидая, что у вас нет каталога с именем /tnt;). Что ж, оно у нас есть !!

Итак, посмотрим:

$ ls -ld /tmp /tnt >/dev/null
ls: cannot access /tnt: No such file or directory

$ ls -ld /tmp /tnt >/dev/null 2>&1

$ ls -ld /tmp /tnt 2>&1 >/dev/null
ls: cannot access /tnt: No such file or directory

Последняя командная строка выгружает STDERR в консоль, и это, похоже, не соответствует ожидаемому поведению ... Но ...

Если вы хотите выполнить фильтрацию сообщений для стандартного вывода, ошибки вывода или того и другого:

$ ls -ld /tmp /tnt | sed 's/^.*$/<-- & --->/'
ls: cannot access /tnt: No such file or directory
<-- drwxrwxrwt 118 root root 196608 Jan  7 12:02 /tmp --->

$ ls -ld /tmp /tnt 2>&1 | sed 's/^.*$/<-- & --->/'
<-- ls: cannot access /tnt: No such file or directory --->
<-- drwxrwxrwt 118 root root 196608 Jan  7 12:02 /tmp --->

$ ls -ld /tmp /tnt >/dev/null | sed 's/^.*$/<-- & --->/'
ls: cannot access /tnt: No such file or directory

$ ls -ld /tmp /tnt >/dev/null 2>&1 | sed 's/^.*$/<-- & --->/'

$ ls -ld /tmp /tnt 2>&1 >/dev/null | sed 's/^.*$/<-- & --->/'
<-- ls: cannot access /tnt: No such file or directory --->

Обратите внимание, что последняя командная строка в этом абзаце точно такая же, как и в предыдущем абзаце, где я написал , похоже, не является ожидаемым поведением (так что это может быть даже ожидаемым поведением).

Что ж, есть небольшие уловки с перенаправлением для выполнения разных операций на обоих выходах:

$ ( ls -ld /tmp /tnt | sed 's/^/O: /' >&9 ) 9>&2  2>&1  | sed 's/^/E: /'
O: drwxrwxrwt 118 root root 196608 Jan  7 12:13 /tmp
E: ls: cannot access /tnt: No such file or directory

Примечание: дескриптор &9 возникнет спонтанно из-за ) 9>&2.

Дополнение: примечание! В новой версии bash (>4.0) есть новая функция и более привлекательный синтаксис для выполнения таких действий:

$ ls -ld /tmp /tnt 2> >(sed 's/^/E: /') > >(sed 's/^/O: /')
O: drwxrwxrwt 17 root root 28672 Nov  5 23:00 /tmp
E: ls: cannot access /tnt: No such file or directory

И, наконец, для такого каскадного форматирования вывода:

$ ((ls -ld /tmp /tnt |sed 's/^/O: /' >&9 ) 2>&1 |sed 's/^/E: /') 9>&1| cat -n
     1  O: drwxrwxrwt 118 root root 196608 Jan  7 12:29 /tmp
     2  E: ls: cannot access /tnt: No such file or directory

Дополнение: примечание! Одинаковый новый синтаксис в обоих направлениях:

$ cat -n <(ls -ld /tmp /tnt 2> >(sed 's/^/E: /') > >(sed 's/^/O: /'))
     1  O: drwxrwxrwt 17 root root 28672 Nov  5 23:00 /tmp
     2  E: ls: cannot access /tnt: No such file or directory

Где STDOUT проходят через определенный фильтр, STDERR - через другой, и, наконец, оба объединенных выхода проходят через третий фильтр команд.

3 - Несколько слов о параметре noclobber и синтаксисе >|

Это о перезаписи:

В то время как set -o noclobber предписывает bash не перезаписывать существующие файлы, >| синтаксис позволяет обойти это ограничение:

$ testfile=$(mktemp /tmp/testNoClobberDate-XXXXXX)

$ date > $testfile ; cat $testfile
Mon Jan  7 13:18:15 CET 2013

$ date > $testfile ; cat $testfile
Mon Jan  7 13:18:19 CET 2013

$ date > $testfile ; cat $testfile
Mon Jan  7 13:18:21 CET 2013

Файл каждый раз перезаписывается, ну а теперь:

$ set -o noclobber

$ date > $testfile ; cat $testfile
bash: /tmp/testNoClobberDate-WW1xi9: cannot overwrite existing file
Mon Jan  7 13:18:21 CET 2013

$ date > $testfile ; cat $testfile
bash: /tmp/testNoClobberDate-WW1xi9: cannot overwrite existing file
Mon Jan  7 13:18:21 CET 2013

Пройдите с >|:

$ date >| $testfile ; cat $testfile
Mon Jan  7 13:18:58 CET 2013

$ date >| $testfile ; cat $testfile
Mon Jan  7 13:19:01 CET 2013

Отключение этой опции и / или запрос, если он уже установлен.

$ set -o | grep noclobber
noclobber           on

$ set +o noclobber

$ set -o | grep noclobber
noclobber           off

$ date > $testfile ; cat $testfile
Mon Jan  7 13:24:27 CET 2013

$ rm $testfile

4 - Последний трюк и многое другое ...

Для перенаправления обоих выходных данных заданной команды мы видим, что правильный синтаксис может быть таким:

$ ls -ld /tmp /tnt >/dev/null 2>&1

для этого особого случая существует сокращенный синтаксис: &> ... или >&

$ ls -ld /tmp /tnt &>/dev/null

$ ls -ld /tmp /tnt >&/dev/null

Примечание: если 2>&1 существует, 1>&2 также является правильным синтаксисом:

$ ls -ld /tmp /tnt 2>/dev/null 1>&2

4b- Теперь я позволю вам подумать о:

$ ls -ld /tmp /tnt 2>&1 1>&2  | sed -e s/^/++/
++/bin/ls: cannot access /tnt: No such file or directory
++drwxrwxrwt 193 root root 196608 Feb  9 11:08 /tmp/

$ ls -ld /tmp /tnt 1>&2 2>&1  | sed -e s/^/++/
/bin/ls: cannot access /tnt: No such file or directory
drwxrwxrwt 193 root root 196608 Feb  9 11:08 /tmp/

4c- Если вас интересует дополнительная информация

Вы можете прочитать прекрасное руководство, нажав:

man -Len -Pless\ +/^REDIRECTION bash

в консоли bash ;-)

Я нашел этот замечательный пост о перенаправлении: Все о перенаправлениях

Перенаправить в файл как стандартный вывод, так и стандартную ошибку

$ команда &> файл

Этот однострочник использует оператор &> для перенаправления обоих выходных потоков - stdout и stderr - от команды к файлу. Это ярлык Bash для быстрого перенаправления обоих потоков в одно и то же место назначения.

Вот как выглядит таблица дескрипторов файлов после того, как Bash перенаправил оба потока:

Как видите, и stdout, и stderr теперь указывают на file. Таким образом, все, что написано в stdout и stderr, записывается в file.

Есть несколько способов перенаправить оба потока в одно и то же место назначения. Вы можете перенаправлять каждый поток один за другим:

$ команда> файл 2> & 1

Это гораздо более распространенный способ перенаправления обоих потоков в файл. Сначала stdout перенаправляется в файл, а затем stderr дублируется, чтобы быть таким же, как stdout. Таким образом, оба потока в конечном итоге указывают на file.

Когда Bash видит несколько перенаправлений, он обрабатывает их слева направо. Давайте пройдемся по шагам и посмотрим, как это произойдет. Перед запуском любых команд таблица файловых дескрипторов Bash выглядит следующим образом:

Теперь Bash обрабатывает первый файл перенаправления>. Мы видели это раньше, и это указывает на то, что stdout указывает на файл:

Далее Bash видит второе перенаправление 2> & 1. Раньше мы не видели этого перенаправления. Он дублирует файловый дескриптор 2, чтобы быть копией файлового дескриптора 1, и мы получаем:

Оба потока перенаправлены в файл.

Однако будьте здесь осторожны! Пишу

команда> файл 2> & 1

это не то же самое, что писать:

$ команда 2> & 1> файл

Порядок перенаправления имеет значение в Bash! Эта команда перенаправляет в файл только стандартный вывод. Stderr по-прежнему будет печатать на терминал. Чтобы понять, почему это происходит, давайте еще раз пройдемся по шагам. Итак, перед запуском команды таблица файловых дескрипторов выглядит так:

Теперь Bash обрабатывает перенаправления слева направо. Сначала он видит 2> & 1, поэтому дублирует stderr на stdout. Таблица файловых дескрипторов становится:

Теперь Bash видит второе перенаправление, >file, и перенаправляет стандартный вывод в файл:

Вы видите, что здесь происходит? Stdout теперь указывает на файл, но stderr по-прежнему указывает на терминал! Все, что записывается в stderr, по-прежнему выводится на экран! Так что будьте очень и очень осторожны с порядком переадресации!

Также обратите внимание, что в Bash написание

$ команда &> файл

точно так же, как:

$ команда> & файл

Цифры относятся к дескрипторам файлов (fd).

• Ноль - это stdin
• Один stdout
• Два stderr

2>&1 перенаправляет fd 2 на 1.

Это работает для любого количества файловых дескрипторов, если программа их использует.

Вы можете посмотреть /usr/include/unistd.h, если забудете их:

/* Standard file descriptors.  */
#define STDIN_FILENO    0   /* Standard input.  */
#define STDOUT_FILENO   1   /* Standard output.  */
#define STDERR_FILENO   2   /* Standard error output.  */

Тем не менее, я написал инструменты C, которые используют нестандартные файловые дескрипторы для пользовательского ведения журнала, поэтому вы не увидите его, если не перенаправите его в файл или что-то в этом роде.

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

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

Вот несколько примеров:

# Look for ERROR string in both stdout and stderr.
foo 2>&1 | grep ERROR

# Run the less pager without stderr screwing up the output.
foo 2>&1 | less

# Send stdout/err to file (with append) and terminal.
foo 2>&1 |tee /dev/tty >>outfile

# Send stderr to normal location and stdout to file.
foo >outfile1 2>&1 >outfile2

Обратите внимание, что последний не перенаправляет stderr на outfile2 - он перенаправляет его на то, что было stdout, когда был обнаружен аргумент (outfile1), а затем перенаправляет stdout на outfile2.

Это позволяет использовать довольно изощренные уловки.

Я нашел это очень полезным, если вы новичок, прочтите это

Обновление:
В системе Linux или Unix есть два места, куда программы отправляют вывод: стандартный вывод (stdout) и стандартная ошибка (stderr). Вы можете перенаправить этот вывод в любой файл.

Как, если вы это сделаете

ls -a > output.txt

Ничего не будет напечатано в консоли, весь вывод (stdout) перенаправляется в выходной файл.

И если вы попытаетесь распечатать содержимое любого файла, который не завершается, это означает, что вывод будет с ошибкой, как если бы вы распечатали test.txt, которого нет в текущем каталоге

cat test.txt > error.txt

Вывод будет

cat: test.txt :No such file or directory

Но файл error.txt будет пустым, потому что мы перенаправляем stdout в файл, а не в stderr.

поэтому нам нужен дескриптор файла (дескриптор файла - это не что иное, как положительное целое число, которое представляет открытый файл. Вы можете сказать, что дескриптор - это уникальный идентификатор файла), чтобы сообщить оболочке, какой тип вывода мы отправляем в файл . В системе Unix / Linux 1 для stdout и 2 для stderr.

так что теперь, если вы это сделаете

ls -a 1> output.txt означает, что вы отправляете стандартный вывод (stdout) в output.txt.

и если вы это сделаете

cat test.txt 2> error.txt означает, что вы отправляете стандартную ошибку (stderr) в error.txt.

&1 используется для ссылки на значение файлового дескриптора 1 (stdout).

Теперь перейдем к делу 2>&1 означает «Перенаправить stderr в то же место, где мы перенаправляем stdout»

Теперь вы можете это сделать
‹br

cat maybefile.txt > output.txt 2>&1

стандартный вывод (stdout) и стандартный вывод ошибок (stderr) будут перенаправлены на output.txt.

Спасибо Ондрею К. за указание

2 - стандартная ошибка консоли.

1 - стандартный вывод консоли.

Это стандартный Unix, и Windows также следует POSIX.

Например. когда ты бежишь

perl test.pl 2>&1

стандартная ошибка перенаправляется на стандартный вывод, поэтому вы можете видеть оба вывода вместе:

perl test.pl > debug.log 2>&1

После выполнения вы можете увидеть весь вывод, включая ошибки, в debug.log.

perl test.pl 1>out.log 2>err.log

Затем стандартный вывод идет в out.log, а стандартная ошибка - в err.log.

Предлагаю вам попытаться понять это.