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

Поднимаясь из этого высоко оцененного комментария, что означает `>>` в терминальной команде?:

"Программа до" Что это значит? Команда, очевидно, но перенаправления также могут быть написаны в начале, то есть >> file command

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

command >> file

когда используешь >> и тому подобное (т.е. 2>, 2>&1, так далее.).

Когда и почему вы бы поменяли порядок? Значит ли это, что все stdout перенаправляется не только с command? У кого-нибудь есть конкретные примеры?

Я имел Google и мог найти любые непосредственные примеры.

2 ответа

Решение

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

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

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

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

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

А также

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

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

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 на более глубоком уровне.

Другие вопросы по тегам