Что делает ">> команда file" и чем она отличается от "команда >> файл"?

>> file command
Значит ли это, что все stdoutперенаправлено, а не только с команды?

Такое перенаправление влияет на простую команду. От man 1 bash:

Перед выполнением команды ее ввод и вывод могут быть перенаправлены с использованием специальных обозначений, интерпретируемых оболочкой. […] Следующие операторы перенаправления могут предшествовать или появляться в любом месте простой команды или могут следовать за командой. Перенаправления обрабатываются в порядке их появления слева направо.

«Следующие операторы перенаправления» являются [n]<word, [n]>word, и [n]>>wordт.д.

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

А также

управляющий оператор
Маркер, выполняющий функцию управления. Это один из следующих символов:
|| & && ; ;; ( ) | |&<newline>

Это означает, что следующие команды эквивалентны:

echo Some text >> file echo Some >> file text echo >> file Some text >> file echo Some text 

Вопрос помечен как bash, и я цитирую, man 1 bashно вышеупомянутые команды также работают sh.

Синтаксический анализатор командной строки должен «обслужить» все перенаправления, прежде чем он выполнит команду (т. Е. Команда, лишенная этих перенаправлений). Подумайте об этом, процедура одна и та же, независимо от того, где находится конкретное перенаправление. Нет причин требовать, чтобы это было в самом конце.

Когда и почему вы бы поменяли порядок?

Я не припоминаю ситуацию, когда я хотел иметь перенаправление в середине. Однако существует случай использования, когда перенаправление ввода в начале довольно полезно. Рассмотрим этот код:

grep foo file | tail | … 

Представьте, что труба очень длинная. Он размещен на Super User и решает некоторые проблемы. Вы можете вставить его в консоль и запустить. Что если вы захотите добавить его к какой-либо команде или каналу? Например, вы хотите получить:

my_custom_command | grep foo | tail | … # ^^^^^^^^^^^^^^^^^^^ this is the part you'd be happy to paste 

Вы должны удалить fileиз скопированной команды. По этой причине некоторые пользователи предпочитают публиковать такие команды:

cat file | grep foo | tail | … # ^^^^^^^^^^^^^^^^^^^ it's easy to copy this # ^^^^^^^^^^^^^^^^^^^^^ or even this 

В других обстоятельствах это было бы совершенно бесполезным cat. Некоторые скажут, что так и есть, независимо от обстоятельств. Как насчет:

< file grep foo | tail | … # ^^^^^^^^^^^^^^^^^^^ it's easy to copy this 

Нет cat и удобной формы!

объяснение

Ключом к пониманию того, как работают операторы перенаправления ввода / вывода, является помнить, что вы работаете в оболочке, которая постоянно печатает в STDOUT или STDERR (в основном) с каждой вводимой вами командой.

>>не волнует, как происходит вывод, но только то, что когда он происходит, он может добавить его в файл, который непосредственно следует за ним. Также важно помнить, что операторы перенаправления не собираются вмешиваться в ваши команды. Вы можете проверить вещи дальше, набрав, echo hello >> newfile this is my outputи когда вы cat newfileувидите: «Привет, это мой вывод».

В этом конкретном случае порядок команд в сочетании с оператором добавления (>>) не обязательно важен для наблюдения. Вместо этого следите за результатами ваших команд, о чем не говорится в комментарии Камиля выше ^. Пока что-то, что не является ошибкой, печатается в вашей оболочке, >>может делать свое дело.

Задача команды echo - печатать на стандартный вывод (STDOUT). Попробуйте сами, и вы увидите новую строку с вашим выводом. Если вы включите >> fileв микс, в этот файл будет добавлено все, что появляется на этой новой строке. Порядок этого является важным, однако. Файл для добавления должен непосредственно следовать за оператором.

Примечание к примерам

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

Если вы хотите еще глубже понять это, вы можете начать изучать файловые дескрипторы (STDIN, STDOUT, STDERR) и как работают системные вызовы Unix . Все это можно увидеть как окно в системное программирование Unix и как работает Unix / Linux на более глубоком уровне.