В чем различия между &> и 2> & 1

Существует две формы перенаправления стандартного выхода и стандартной ошибки на стандартный выход . Но какой из них лучше? и почему &> считается идеальным?

Я не могу найти, в чем различия, так что многие учебники и даже руководство по bash утверждают, что &> лучше!

Так почему я должен использовать &>, а не 2>&1

В основном использовать bash оболочку


РЕДАКТИРОВАТЬ: Спасибо за комментарии

Только> & работает в csh или tcsh

В ksh работает только 2> & 1.

dash use> file 2> & 1 redirection redirection

Тогда какой из них использовать для обеспечения совместимости моего скрипта с другими системами, какими бы ни были используемые оболочки!

26
задан 12.06.2015, 00:02

4 ответа

Страница справочника Bash упоминает, что существует два способа перенаправить stderr и stdout: &> file и >& file. Теперь, заметьте, что это говорит и stderr и stdout.

В случае этого >file 2>&1 мы делаем перенаправление stdout (1) в файл, но тогда также говорим stderr (2) быть перенаправленным к тому же месту как stdout! Таким образом, целью может быть то же, но немного отличающаяся идея. Другими словами, "John, пойдите в школу; Suzzie идут, куда John идет".

Что относительно предпочтения? &> bash вещь. Таким образом, при портировании сценария так не пойдет он. Но если Вы на 100% уверены, что Ваш сценарий будет только работать над системой с ударом - тогда нет никакого предпочтения

, Вот пример с dash, Shell Debian Amquist, который является значением по умолчанию Ubuntu.

$ grep "YOLO" * &> /dev/null
$ grep: Desktop: Is a directory
grep: Documents: Is a directory
grep: Downloads: Is a directory
grep: Music: Is a directory
grep: Pictures: Is a directory
grep: Public: Is a directory
grep: Templates: Is a directory
grep: Videos: Is a directory
grep: YOLO: Is a directory
grep: bin: Is a directory

, Как Вы видите, stderr не перенаправляется

Для обращения к редактированиям в вопросе, можно использовать, если оператор для проверки переменной $SHELL и изменения перенаправляет соответственно

, Но для большинства случаев > file 2>&1 должен работать

<час>

В большем количестве технических терминов, форму [integer]>&word называют Дескриптор Выходного файла Дублирования и является функцией, определенной POSIX стандарт Командного языка Shell, который поддерживается большинством совместимых POSIX и подобных Brourne оболочек.

Видят также , Что делает & иметь в виду точно в перенаправлении вывода?

0
ответ дан 17.04.2019, 22:23
  • 1
    Тогда, что происходит при использовании на некоторых других оболочках? – Wilson.Hwang 11.06.2015, 23:56
  • 2
    поддержки zsh &>.... @Maythux В оболочках, которые не поддерживают &>, например, dash, необходимо использовать тривиальное >file 2>&1 перенаправление.. – Jack 11.06.2015, 23:58
  • 3
    Тогда, Который использовать, если я хочу быть уверенным, мой сценарий будет совместим с различными оболочками – John Wu 11.06.2015, 23:59
  • 4
    Использование @Maythux >file 2>&1. Эта работа над всеми оболочками – BACON 12.06.2015, 00:01
  • 5
    Набор оболочек @TSJNachos117 в /etc/passwd для каждого пользователя является интерактивными оболочками. Системные сценарии обычно для dash, если иначе не определено. Что касается того, что является значением по умолчанию, it' s определенный тем, что является symlinked к /bin/sh В Ubuntu' s случай that' s dash. В RHEL it' s bash в FreeBSD, который это tcsh источник и другой источник – Jack 17.07.2016, 14:15

Итак, почему буду, я использую &> и не 2> & 1

2>&1 стандартная оболочка Границы/POSIX.

&> расширение удара а не де-юре стандарт.

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

0
ответ дан 17.04.2019, 22:23

От Справочник Bash-> 3.6.4 Стандартных выводов Перенаправления и Стандартная погрешность :

Эта конструкция позволяет обоим стандартный вывод (дескриптор файла 1) и вывод стандартной погрешности (дескриптор файла 2), чтобы быть перенаправленной в файл, имя которого является расширением слова.

существует два формата для перенаправления стандартного вывода и стандартной погрешности:

&>word

и

>&word

Из двух форм, первое предпочтено. Это семантически эквивалентно [1 116]

>word 2>&1

При использовании второй формы, слово не может расшириться до числа или †˜-’. Если это делает, другие операторы перенаправления применяются (см. Дескрипторы файлов Дублирования ниже) по причинам совместимости.

Также хороший для обращения к Wiki Greg на Вводе и выводе-> 4.2. Управление Дескриптором файла :

Для удобства, Bash также делает еще одну форму к перенаправлению доступной для Вас. &> оператор перенаправления является на самом деле просто более короткой версией того, что мы сделали здесь [2>&1]; перенаправление и stdout и stderr в файл.

0
ответ дан 17.04.2019, 22:23

Я обычно рекомендовал бы после способа Перенесенной Оболочки сделать вещи, так как удар является возможно самой популярной оболочкой 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, оба из которых имели бы тот же эффект как использование &>. Если Вы сделаете что-то как [1 110], то только stdout будет перенаправлен, но stderr может все еще быть передан по каналу к другой программе, такой как кошка, которая могла быть перенаправлена как показано выше. Однако ввод &> легче, чем любой из вышеупомянутых примеров, начиная с него включает ввод меньшего количества символов (и для людей немного легче читать). Действительно обратите внимание, что program 2> log.txt > log.txt могло бы быть более вероятно работать над оболочками неудара.

пз: если Вы волнуетесь по поводу людей, использующих другие оболочки, существует что-то, что можно добавить, чтобы быть первой строкой сценария, названного "магическим числом" или "хижиной". Это - по существу способ удостовериться, что другие компьютеры (особенно те, которые выполняют подобные Unix операционные системы), знают который программа использовать для выполнения сценария. Различные сценарии используют различные хижины. Хижина для сценария удара похожа на это:

#!/bin/bash

, Если Вы используете вышеупомянутое в качестве первой строки данного сценария, удар будет обычно использоваться для выполнения было, сказано в сценарии. Это сделает намного более трудным для кого-то случайно выполнить сценарий с неправильной оболочкой.

пз: я не собираюсь лежать: до настоящего времени я не знал, что можно было использовать >&, но, насколько удар идет, это, кажется, делает то же как [1 114]. Вы каждый день изучаете что-то новое.

0
ответ дан 17.04.2019, 22:23
  • 1
    В то время как я действительно соглашаюсь с Вами об использовании #! строка для явного запроса bash, это не всегда доступно в других системах. Очень часто разработчики/системные администраторы должны записать портативные сценарии для систем, в которых bash может не быть доступным, и это не может находиться под их контролем для установки bash. Эти >file 2>&1 просто много портативного устройства. – BACON 17.07.2016, 15:29
  • 2
    Вы совершили ошибку реверсирования выше, которая не приводит к результату, которого Вы требуете или хотите. Перенаправьте stderr к stdout, затем перенаправьте листы stdout stderr на исходном stdout. – Youfa Mao 17.07.2016, 15:48
  • 3
    Serg: Я didn' t средний для допущения удара было универсально. Однако я думаю, что больше людей использует его, чем говорят (t) csh. Если Вы don' t знают то, что кто-то еще использует и должен высказать слепое предположение, удар является, вероятно, Вашим лучшим выбором. Кроме того, я обычно don' t знают о мобильности, так как я только использую удар. То, которое >file 2>&1 более портативно, хорошо для знания. I' ll делают редактирование для отражения этого. – Thillainathan Sarubi 23.07.2016, 15:08
  • 4
    Ubfan1, спасибо за информацию. Я никогда не предполагал бы через миллион лет тот удар wouldn' t перенаправляют stderr в файл в этом случае. I' ve просто отредактировал мой ответ, чтобы препятствовать тому, чтобы другие делали ту же ошибку. – Youfa Mao 23.07.2016, 15:16

Теги

Похожие вопросы