Печать в STDOUT по сравнению с прямой записью в выходной файл

Несколько практических примеров:

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

Однако, с другой стороны, вариант -o <output-file-name>обычно предпочтительнее, если приложению скорее требуется поиск по выходным данным.

Конечно, вы также можете lseek(2)заменить стандартный вывод (, если он действительно доступен для поиска ), но это обычно неожиданное поведение.

Естественно, то же самое верно и для ввода.

Для перенаправления из/в файл требуется оболочка. Специальный аргумент option позволяет не требовать оболочки.

Перенаправление из/в файл позволяет легко обмениваться положением этого файла (, если он доступен для поиска ), или соединением этого канала/сокета между несколькими приложениями, что может быть полезным в сценариях оболочки, например, в:

{
    echo hello world
    head -c 10
    seq 10 | awk '{print "amazing text-manipulation of", $0}'
    dd bs=1024 count=1 seek=32
    echo farewell
} < /dev/random > recipient-file

Полагаться только на -o recipient-fileвариант (или-i /dev/random)не позволит (так просто ).

В некоторых случаях противоположное вышеприведенному также может иметь место :опция -o <output-file-name>позволяет сделать вывод этого приложения не загрязняющим стандартный вывод при совместном использовании его с другими приложениями, например, в:

strace -o prog.strace output-producer > prog.output

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

unwanted-consumer -i /dev/null desired-consumer

Если полагаться только на stdin/stdout, потребуется дополнительный уровень оболочки, как в:

strace > prog.strace sh -c 'output-producer > prog.output'

или для стандартного ввода:

unwanted-consumer 3<&0 < /dev/null sh -c 'desired-consumer <&3'

Помимо компактности/чистоты команды, а также того, что вообще не требуется оболочка, вызов оболочки включает в себя несколько другую среду, и вам может потребоваться настроить ее для output-producerили desired-consumer, что увеличивает общую нагрузку.

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

С другой стороны, если выходные данные обычно двоичные или очень большие (по сравнению с входными данными ), то может иметь смысл запрашивать имя файла по умолчанию и отказываться от печати на терминале, если только явно спросил.

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

Для второго варианта рассмотрим, например. convertот ImageMagick, который может конвертировать и обрабатывать файлы изображений. Он принимает имена входных и выходных файлов в командной строке. Здесь файл изображения реже используется как часть конвейера, и на практике никто не хочет, чтобы JPEG или PNG выгружались на их терминал, поэтому здесь имеет смысл сделать это таким образом.

При использовании аргументов имени файла может быть хорошей идеей разрешить -обозначать stdin или stdout, при условии, что вы задокументируете это. Это довольно распространенный обычай, избавляющий пользователя от необходимости использовать вместо него что-то вроде /dev/stdin. (И это может привести к сбою в некоторых системах.)

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