Каковы соглашения для сообщений stdout / stderr? - PullRequest
2 голосов
/ 02 ноября 2011

У меня есть приложение, которое fprintf выводит как справку, так и сообщения об ошибках на stderr.

Должен ли я отправлять сообщения на stdout, если я выхожу со статусом EXIT_SUCCESS (например, когда я запускаю опцию --help для моего приложения)?

Аналогично, я должен продолжать отправлять сообщения об ошибках на stderr на EXIT_FAILURE?

Или я должен отправить все справки и сообщения об ошибках на stdout?

Каковы общие соглашения для этого с POSIX-совместимыми приложениями UNIX?

Ответы [ 4 ]

6 голосов
/ 02 ноября 2011

Очевидно, что сообщения об ошибках должны идти на stderr, потому что вы не хотите перехватывать их при перенаправлении стандартного вывода.

Когда использование отображается из-за того, что какой-либо параметр командной строки использовался неверно, он отображается как (часть) сообщения об ошибке. Таким образом, он должен перейти к stderr и вызвать EXIT_FAILURE.

Когда использование отображается, потому что пользователь запросил его через --help, оно отображается как желаемое поведение при вызове команды. Таким образом, он должен перейти к stdout, и команда должна завершиться успешно с EXIT_SUCCESS.

Это кратко описано в стандартах кодирования GNU .

3 голосов
/ 02 ноября 2011

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

Однако, по моему не столь скромному мнению, мне не нравятся приложения, которые пишут свой текст справки на stderrпотому что сложнее сделать простой grep для текста.Я бы сказал, что 50/50, какие программы это делают, а какие нет.

2 голосов
/ 21 декабря 2016

Posix определяет стандартные потоки , таким образом :

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

Библиотека GNU C описывает стандартные потоки аналогично:

Переменная: ФАЙЛ * стандартный вывод
Стандартный поток вывода, который используется для нормального вывода из программы.

Переменная: ФАЙЛ * stderr
Стандартный поток ошибок, который используется для сообщений об ошибках и диагностики, выдаваемых программой.

Таким образом, стандартные определения имеют небольшое руководство по использованию потока, помимо «обычного / нормального вывода» и «вывода диагностики / ошибки». На практике часто перенаправляют один или оба этих потока в файлы и конвейеры, поэтому рассмотрите вероятную использование. Обычный вывод должен доходить до stdout, , особенно , если пользователи могут grep или иным образом проанализировать его. В частности, текст справки должен указывать на stdout, чтобы его можно было легко найти и просмотреть. Некоторые системы контролируют stderr для вывода и считают это признаком проблем, поэтому обычно используют его только для фактических ошибок и других важных диагностик. И наконец, отправляйте интерактивный вывод (например, индикаторы хода выполнения) только в том случае, если поток действительно интерактивен (например, как сообщается в isatty) или когда он явно включен параметром командной строки.

1 голос
/ 02 ноября 2011

Используя strace, вы можете обнаружить, что многие утилиты GNU / Linux (например, ls, date, gcc, make ...) выводят свои --help в стандартный вывод .Я предлагаю поступить так, как они.

...