Существует две формы перенаправления стандартного вывода и стандартной ошибки в стандартный вывод . Но какой из них лучше? а почему то &>
считается идеальным?
Я не могу найти, в чем различия, так что многие руководства и даже руководство по bash указывают, что &>
лучше!
Так почему я должен использовать, &>
а не2>&1
В основном с использованием bash
оболочки
РЕДАКТИРОВАТЬ: Спасибо за комментарии
Только> & работает в csh или tcsh
В ksh работает только 2> & 1.
dash use> file 2> & 1 redirection
Тогда какой из них использовать для обеспечения совместимости моего скрипта с другими системами, какими бы ни были используемые оболочки!
command-line
bash
redirect
Maythux
источник
источник
&> somewhere
это просто сокращение от bash> somewhere 2>&1
: по словам руководства bash, они «симметрично эквивалентны»Ответы:
На странице руководства Bash упоминается, что существует два способа перенаправления stderr и stdout :
&> file
и>& file
. Теперь обратите внимание, что это говорит и stderr и stdout.В этом случае
>file 2>&1
мы выполняем перенаправление stdout (1) в файл, а затем говорим, что stderr (2) следует перенаправить в то же место, что и stdout! Так что цель может быть одна и та же, но идея немного другая. Другими словами "Джон, иди в школу; Сьюзи, иди туда, куда идет Джон".А как насчет предпочтений?
&>
этоbash
вещь. Так что, если вы переносите скрипт, он этого не сделает. Но если вы на 100% уверены, что ваш скрипт будет работать только в системе с bash - тогда нет никаких предпочтенийВот пример с
dash
оболочкой Debian Amquist, которая используется по умолчанию в Ubuntu.Как видите, stderr не перенаправляется
Чтобы исправить изменения в вопросе, вы можете использовать оператор if для проверки переменной $ SHELL и изменения перенаправлений соответственно.
Но для большинства случаев
> file 2>&1
должно работатьВ более технических терминах форма
[integer]>&word
называется Дублирование дескриптора выходного файла и является функцией, определяемой стандартом POSIX Shell Command Language, который поддерживается большинством POSIX-совместимых и Brourne-подобных оболочек.Смотрите также Что означает и что конкретно означает перенаправление вывода?
источник
&>
.... @Maythux В оболочках, которые не поддерживают,&>
например,dash
вам нужно использовать тривиальное>file 2>&1
перенаправление ..>file 2>&1
. Эта работа на всех снарядах/etc/passwd
для каждого пользователя, являются интерактивными оболочками. Системные сценарии обычно предназначены для,dash
если не указано иное. Что касается того, что по умолчанию, это определяется тем, что символически связано с делом в/bin/sh
Ubuntudash
. В RHEL это естьbash
, во FreeBSD этоtcsh
источник и еще один источникВ общем, я бы рекомендовал следовать образу действий Bourne-again SHell , поскольку bash, пожалуй, самая популярная оболочка Unix. Bash обычно использует либо
&>
или2>&1
. ИМХО, ни то, ни другое "идеально", поэтому я рекомендую забыть об этой ерунде. Реально, какой из них вы должны использовать, зависит от того, что вы пытаетесь сделать.2>&1
объединяет stderr с stdout, что может быть полезно, если, например, вы хотите передать текст stderr. Так, например, если вы хотите увидеть, печатает ли программа определенное сообщение stderr, но не хотите, чтобы ваш экран заполнялся (предположительно) неважным мусором, вы можете сделать что-то вроде этогоprogram 2>&1 | grep crashed
, который будет искать stdout и stderr из программы называется "программа" для слова "разбился".С другой стороны, если вы не хотите, чтобы программа вообще что-либо печатала, вы можете просто запустить
program &> /dev/null
, что перенаправит и stderr, и stdout в / dev / null, специальный файл, который волшебным образом заставляет вещи исчезнуть. Или, если вы хотите сохранить выходные данные программы (возможно, сообщить об ошибке или что-то в этом роде), вы можете перенаправить как stderr, так и stdout в файл:program &> log.txt
перенаправит все данные в файл с именем «log.txt». Если вы хотите, вы можете перенаправить stdout и stderr черезprogram 2> log.txt > log.txt
илиprogram 2>&1 | cat > log.txt
, оба из которых будут иметь тот же эффект, что и при использовании&>
. Если вы сделаете что-то подобноеprogram 2>&1 > file
, будет перенаправлен только stdout, но stderr все еще может быть передан другой программе, например, cat, которую можно перенаправить, как показано выше. Тем не менее, набрав&>
это проще, чем в любом из приведенных выше примеров, поскольку включает в себя ввод меньшего количества символов (и людям немного легче читать). Обратите внимание, что этоprogram 2> log.txt > log.txt
может с большей вероятностью работать на оболочках, отличных от bash.PS: если вы беспокоитесь о людях, использующих другие оболочки, есть что-то, что вы можете добавить в первую строку вашего сценария, называемое «магическим числом» или «шебанг». По сути, это способ убедиться, что другие компьютеры (особенно те, на которых работают Unix-подобные операционные системы) знают, какую программу использовать для выполнения скрипта. Разные сценарии используют разные шебанги. Шебанг для сценария bash выглядит так:
Если вы используете вышеперечисленное в качестве первой строки данного скрипта, bash обычно будет использоваться для выполнения указанного скрипта. Это значительно усложнит случайное выполнение сценария с неверной оболочкой.
PS: я не собираюсь лгать: до сих пор я не знал, что можно использовать
>&
, но, что касается bash, похоже, он делает то же самое, что и&>
. Ты узнаешь что-то новое каждый день.источник
#!
строки для явного запросаbash
, она не всегда доступна в других системах. Очень часто разработчикам / системным администраторам приходится писать переносимые сценарии для систем, на которых ониbash
могут быть недоступны, а установка может быть не под их контролемbash
. Это>file 2>&1
просто очень портативный.>file 2>&1
он более портативный, это хорошо знать. Я сделаю правку, чтобы отразить это.Из справочного руководства Bash -> 3.6.4 Перенаправление стандартного вывода и стандартной ошибки :
Также полезно обратиться к вики Грега по вводу и выводу -> 4.2. Манипуляция дескриптором файла :
источник
2>&1
стандартная оболочка Bourne / POSIX&>
является расширением bash, а не стандартом де-юре .Если вы пишете сценарии с использованием расширений bash, рано или поздно вы столкнетесь со сбоем в голове с зашифрованными сообщениями об ошибках синтаксиса, поскольку они запускаются в стандартной оболочке.
источник