Должен ли я заботиться о ненужных кошках?

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

сравнить

sed s/bla/blaha/ data \
| grep blah \
| grep -n babla

а также

cat data \
| sed s/bla/blaha/ \
| grep blah \
| grep -n babla

Последний метод менее эффективен? Если да, то достаточно ли разницы, чтобы заботиться о том, запускается ли скрипт, скажем, раз в секунду? Разница в читаемости не огромна.

«Окончательный» ответ, конечно же, принес вам «Бесполезное использование catнаграды» .

Цель cat состоит в том, чтобы объединять (или «связывать») файлы. Если это всего лишь один файл, то его объединение вообще ни с чем не является пустой тратой времени и стоит вам процесса.

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

Как вы заметили, большинство программ могут принимать аргумент для входного файла. Однако всегда есть встроенная оболочка, <которую можно использовать везде, где ожидается поток STDIN, который сэкономит вам один процесс, выполнив работу в уже запущенном процессе оболочки.

Вы даже можете проявить творческий подход, ГДЕ вы пишете. Обычно это будет помещено в конец команды, прежде чем вы укажете какие-либо перенаправления вывода или каналы, как это:

sed s/blah/blaha/ < data | pipe

Но так не должно быть. Это может даже прийти первым. Например, ваш пример кода может быть написан так:

< data \
    sed s/bla/blaha/ |
    grep blah |
    grep -n babla

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

function fix_blahs () {
    sed s/bla/blaha/ |
    grep blah |
    grep -n babla
}

fix_blahs < data

Затем вы можете продолжить fix_blahs < data | fix_frogs | reorder | format_for_sql. Пипллайн, который читается так, очень легко следовать, и отдельные компоненты могут быть легко отлажены в своих соответствующих функциях.

Вот краткое изложение некоторых недостатков:

cat $file | cmd

над

< $file cmd

• Во-первых, примечание: здесь (намеренно для целей обсуждения) пропущены двойные кавычки $file. В случае cat, это всегда проблема, за исключением zsh; в случае перенаправления это проблема только для bashили, ksh88а для некоторых других оболочек только в интерактивном режиме (не в сценариях).
• Наиболее часто упоминаемый недостаток - дополнительный процесс, который порождается. Обратите внимание, что если cmdвстроен, это даже 2 процесса в некоторых оболочках, как bash.
• Все еще на переднем плане производительности, за исключением catвстроенных оболочек , в которых также выполняется дополнительная команда (и, конечно, она загружается и инициализируется (и библиотеки, с которыми она связана)).
• Еще на фронте производительности для больших файлов, это означает , что система должна поочередно графику catи cmdпроцессы и постоянно пополняет и опустошение буфера трубы. Даже если за один раз cmdвыполняются 1GBбольшие read()системные вызовы, управление должно идти назад и вперед между catи cmdпотому, что канал не может хранить более нескольких килобайт данных за раз.
• Некоторые cmds (например wc -c) могут выполнять некоторую оптимизацию, когда их стандартный stdin - это обычный файл, с которым они не могут работать, так cat | cmdкак их стандартный stdin - это просто канал. С catи труба, это также означает, что они не могут seek()в файле. Для таких команд, как tacили tail, это имеет огромное значение для производительности, так как это означает, что catони должны хранить весь ввод в памяти.
• И cat $fileдаже его более правильная версия cat -- "$file"не будет работать должным образом для некоторых конкретных имен файлов, таких как -( --helpили что-нибудь, начиная с, -если вы забудете --). Если кто-то настаивает на использовании cat, он, вероятно, должен использовать cat < "$file" | cmdвместо этого для надежности.
• Если $fileне может быть открыт для чтения (доступ запрещен, не существует ...), < "$file" cmdсообщит о непротиворечивом сообщении об ошибке (оболочкой) и не запустится cmd, пока cat $file | cmdбудет работать, cmdно с его stdin, похожим на пустой файл. Это также означает, что в таких вещах, как < file cmd > file2, file2не засоряется, если fileне может быть открыт.

Помещение <fileв конец конвейера менее читабельно, чем cat fileв начале. Естественный английский читает слева направо.

Ввод <fileначало трубопровода также менее читабельным , чем кошки, я бы сказал. Слово более читабельно, чем символ, особенно символ, который, кажется, указывает неправильный путь.

Использование catсохраняет command | command | commandформат.

Одна вещь, на которую другие ответы здесь, похоже, не имеют прямого отношения, заключается в том, что такое использование catне является «бесполезным» в том смысле, что «возникает процесс постороннего кота, который не работает»; это бесполезно в том смысле, что «создается процесс кошки, который выполняет только ненужную работу».

В случае этих двух:

sed 's/foo/bar/' somefile
<somefile sed 's/foo/bar/'

оболочка запускает процесс sed, который читает из somefile или stdin (соответственно), а затем выполняет некоторую обработку - он читает до попадания на новую строку, заменяет первый «foo» (если есть) в этой строке на «bar», затем печатает эта строка в стандартный вывод и петли.

На случай, если:

cat somefile | sed 's/foo/bar/'

Оболочка порождает процессы cat и sed, и подключает stdout cat к stdin sed. Процесс cat считывает фрагмент из нескольких килобайт или, возможно, мегабайт, из файла, а затем записывает это в свой стандартный вывод, откуда оттуда берется команда sed, как во втором примере выше. Пока sed обрабатывает этот чанк, cat читает другой чанк и записывает его в свой стандартный вывод, чтобы sed мог продолжить работу с ним.

Другими словами, дополнительная работа, необходимая для добавления catкоманды, - это не просто дополнительная работа по созданию дополнительного catпроцесса, это также дополнительная работа по чтению и записи байтов файла дважды, а не один раз. Теперь, если говорить практически и на современных системах, это не имеет большого значения - это может заставить вашу систему выполнить несколько микросекунд ненужной работы. Но если это сценарий, который вы планируете распространять, возможно, людям, использующим его на машинах, которые уже недостаточно загружены, несколько микросекунд могут сложиться за много итераций.