Как я мог помнить, как использовать перенаправление?

Вывод лучше, чем ошибка, таким образом, это на первом месте (1 по сравнению с 2).

> сокращение от, 'переходит в'. Слева то, что я хочу отправить, и справа то, где я хочу отправить его. С тех пор, 'где' (почти) всегда файл, что-то как

program > /dev/null 2>1

перенаправил бы в файл, названный 1. Таким образом, амперсанд (&) изменяет файл к дескриптору файла.

К сожалению, я не столкнулся, ни разработал свою собственную мнемосхему, но когда я сначала учился *, отклоняют, я нашел этот логический способ работать хорошо. После нескольких просмотров это становится второй натурой.

Один прием должен только помнить что 1 = стандартный вывод, 2 = стандартная погрешность. Так:

2>&1 = поток стандартной погрешности входит в поток стандартного вывода.
1>&2 = наоборот.

Если Вы когда-либо программировали в подобном языку C, легко помнить амперсанд (&). Я принимаю решение думать о нем как относящийся к "адресу" существующего дескриптора файла, так, чтобы Вы не изменили сам файл или создали новый.

Наблюдение & поскольку узел мог бы помочь: думайте о том, что Вы хотите сделать как взятие вывода 2, таким образом, 2>, и связь его вместе с 1, таким образом, 2>&1

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

program &> file

Потяните его в своих обоях.

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

Давайте рассмотрим эти три возможности:

program  2>1
program  2>1& 
program  2>&1

Первое отправляет stderr в имена файлов "1": в конце концов, удар ожидает перенаправлять в файл.

Второе также перенаправляет в тот же файл, но выполнения program в фоновом режиме: именно это запаздывание & как предполагается, означает.

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

Как помнить, который является который среди 0, 1, 2? Думайте о выполнении компьютера от консоли. Во-первых, необходимо ввести что-то (0=stdin). Затем Вы видите вывод (1=stdout). Наконец и только если что-то идет не так, как надо, Вы видите stderr (2).

Что касается оболочки bash Я считаю, что лучший способ помнить - это понимать, что происходит.
Если все, что вам нужно, это вспомнить, как правильно выполнить команду, вы можете попробовать

program > /results 2> /results

Это хорошо и очевидно, и это легко запомнить. т.е.

• 1 STDOUT собирается в / results
• 2 STDERR также идет напрямую в / results

проблема в том, что это не работать так, как вы ожидаете. рассмотрите следующее:

файл: /tmp/poem.txt

the quick brown fox jumped over the lazy dog

и запустите команду

grep "brown" /tmp/poem.txt NOT_A_FILE > /tmp/results 2> /tmp/results

, затем

$ cat /tmp/results
grep: NOT_A_FILE: No such file or directory
 lazy dog

, что здесь произошло?
Насколько я понимаю, это установка bash перенаправление указывает STDERR непосредственно на файл / tmp / results и из-за характера > , который обычно выполняет 2 действия

1. создает новый файл - в этом случае возможность упущена, поскольку bash прошел мимо этой процедуры во время генерации вывода.
2. вставить прямо в начало файла. а не добавлять, как >> .

Таким образом, в этом случае STDERR вставляется непосредственно в начало / tmp / results , перекрывая вывод STDOUT.
Примечание: если вы использовали >> для добавления, вы, вероятно, могли бы обойтись без этого синтаксиса.
Однако для решения проблемы вам нужно - не перенаправлять STDERR - в файл напрямую, а скорее объединить вывод STDERR в поток STDOUT, чтобы вы не получили столкновение.
Использование оператора 2> & 1 позволяет добиться этого

grep "brown" poem.txt NOT_A_FILE > /tmp/results 2>&1

& позволяет bash отличать файл с именем 1 и дескриптор файла 1 .
Для меня утверждение 2> & 1 в точности объясняет, что происходит - STDERR перенаправляется на сам STDOUT - и заканчивается только в / tmp / results , потому что именно здесь указывается STDOUT (почти как побочный эффект).
В отличие от того, что утверждают многие руководства, это то, что 2> & 1 отправляет STDERR туда, куда указывает STDOUT. Если бы это было правдой, у вас все равно была бы проблема с перезаписью.

Для получения дополнительной информации см. - http://mywiki.wooledge.org/BashGuide/InputAndOutput#File_Redirection

Читать 2>&1как перенаправление stderr (2 ), куда stdout (1 )в настоящее время .

По мере чтения (и обработки )слева направо. Правильное чтение >file 2>&1— это прямой вывод stdout в файл, а затем прямой вывод stderr в то же место, куда сейчас направляется stdout.

FWIW, чтобы предложить больше ответа «научите человека ловить рыбу», поскольку другие ответы, которые вы получили здесь, говорят, что означает 2>&1, вы всегда можете использовать https://explainshell.com, когда вы не совсем понимаете, что происходит. Это не идеально, но дает неплохую отправную точку при анализе команд bash/shell.

напр. На ваш вопрос:https://explainshell.com/explain?cmd=program+%3E+%2Fdev%2Fnull+2%3E%261