Когда использовать стандартный поток ошибок в приложении командной строки?

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

В частности, вопрос, который я сейчас рассматриваю, заключается в том, следует ли использовать stdout или stderr когда пользователь вызывает программу с незаконными аргументами. Тем не менее, более всеобъемлющий ответ очень ценится, потому что это, безусловно, не будет единственным случаем, когда требуется четкое правило для написания программы, которая ведет себя так, как ожидается от пользователя.

2 Solutions collect form web for “Когда использовать стандартный поток ошибок в приложении командной строки?”

Да, выводите сообщение на stderr когда используются неправильные аргументы. И если это также заставляет приложение выйти, выйдите с ненулевым статусом выхода.

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

Многие оболочки (все?) Отображают подсказки, типы пользователей, а также меню и т. Д. На stderr так что перенаправление stdout не остановит вас от взаимодействия с оболочкой значимым образом.

Из сообщения в блоге по этой теме:

Это цитата из Дуга Макилроя, изобретателя труб Unix, объясняющая, как появился stderr . «v6» относится к версии конкретной версии исходной операционной системы Unix, выпущенной в 1975 году.

Все программы размещали диагностику на стандартном выходе. Это всегда вызывало проблемы, когда выход был перенаправлен в файл, но стал невыносимым, когда вывод был отправлен в ничего не подозревающий процесс. Тем не менее, не желая нарушать простоту модели стандартного ввода-стандарта-вывода, люди переносили это положение через v6. Вскоре после этого Деннис Ритчи разрезал гордиев узел, представив стандартный файл ошибок. Этого было недостаточно. Диагностика трубопроводов может исходить из любой из нескольких запущенных одновременно программ. Диагностика должна была идентифицировать себя.
– Даг Макиллрой, «Исследовательский UNIX-ридер: аннотированные выдержки из руководства для программистов, 1971-1986 годы»

Чтобы «идентифицировать себя» означает просто сказать «Эй, это я говорю! Это пошло не так: […]»:

 $ ls nothere ls: nothere: No such file or directory 

Выполнение этого на stderr предпочтительнее, поскольку в противном случае его можно было бы прочитать любым чтением на stdout (но мы не делаем этого с ls любом случае , не так ли?).

Из спецификаций POSIX для стандартных потоков:

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

Другими словами, ошибки, информация об отладке и все, что попадает в категорию диагностики, отправляются в stderr .

Дополнительную информацию см. В соответствующем вопросе: Имеются ли отчеты о ходе работы / данные регистрации на stderr или stdout?

  • что подразумевается под подключением STDOUT и STDIN?
  • Как кодировать разные типы данных для STDOUT, чтобы STDIN мог определить, что это такое?
  • Перенаправление stderr скрипта Ruby не работает должным образом
  • Подавить предупреждение версий rbenv, если рубины не установлены
  • Как ограничить количество строк выходом команды в bash?
  • Есть ли команда типа «tee», которая ограничивает размер файла и обрабатывает выходной файл как очередь с фиксированным размером?
  • Предполагаемое поведение stdbuf для подпроцессов
  • неблокирующая / многопоточная кошка
  • Чтение и запись в файл из stdin и stdout
  • как перенаправить вывод ssh в файл
  • Как программы с программным обеспечением с оболочкой уравновешивают скорость вывода / ввода?
  • Linux и Unix - лучшая ОС в мире.