Относятся ли отчеты о проделанной работе / журналы к stderr или stdout?

Существует ли официальное руководство по POSIX, GNU или другим правилам о том, где следует печатать отчеты о ходе работы и информацию о регистрации (например, «Doing foo; foo done»)? Лично я склонен записывать их в stderr, чтобы я мог перенаправить stdout и получать только фактический вывод программы. Мне недавно сказали, что это нехорошая практика, поскольку отчеты о ходе работы на самом деле не являются ошибками, и в stderr следует печатать только сообщения об ошибках.

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

У нас есть несколько похожих вопросов, но они не решают эту проблему:

• Когда использовать перенаправление на stderr в сценариях оболочки : принятый ответ предполагает, что я склонен делать, сохраняйте окончательный вывод программы на stdout и все остальное на stderr. Тем не менее, это просто представлено как мнение пользователя, хотя и подтверждается аргументами.

• Должно ли сообщение об использовании идти в stderr или stdout? Это относится только к справочным сообщениям, но цитирует стандарт кодирования GNU. Это то, что я ищу, но не ограничивается только сообщениями о помощи.

Итак, существуют ли какие-либо официальные правила о том, где следует печатать отчеты о ходе работы и другие информационные сообщения (которые не являются частью фактического результата программы)?

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

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

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

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

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

Таким образом, стандартные определения имеют небольшое руководство для использования потока, помимо «обычного / нормального вывода» и «вывода диагностики / ошибки». На практике часто перенаправляют один или оба этих потока в файлы и конвейеры, где проблемы прогресса будут проблемой , Некоторые системы даже отслеживают stderr вывод и считают это признаком проблем. Поэтому чисто вспомогательная информация о прогрессе проблематична в любом потоке.

Вместо того, чтобы отправлять индикаторы хода выполнения безоговорочно в любой стандартный поток, важно понимать, что вывод хода выполнения подходит только для интерактивных потоков. Имея это в виду, я рекомендую записывать счетчики хода выполнения только после проверки, является ли поток интерактивным (например, с помощью isatty()) или когда он явно включен параметром командной строки. Это особенно важно для индикаторов прогресса, которые имеют смысл в поведении обновления терминала, например, в% -заполненных барах.

Для некоторых очень простых сообщений о ходе выполнения («Начало X» ... «Готово с X») более разумно включить вывод даже для неинтерактивных потоков. В этом случае подумайте о том, как пользователи могут взаимодействовать с потоками, например, выполнять поиск grepили пейджинг lessили мониторинг tail -f. Если имеет смысл видеть сообщения о прогрессе в этих контекстах, их будет намного легче использовать stdout.

POSIX определяет стандартную ошибку как

для записи диагностического вывода

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

POSIX немного конкретнее о «диагностической информации» в Shell и Utilities , 1.4: Описание утилит по умолчанию (выделено мной):

STDERR

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

Формат диагностических сообщений для большинства утилит не определен, но настройка LC_MESSAGES и [XSI] [Option Start не должна указывать на языковые и культурные соглашения диагностических и информационных сообщений, формат которых не указан в этом томе POSIX.1-2008. ] NLSPATH. [Вариант Конец]

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

Поведение по умолчанию : если этот раздел указан как «Стандартная ошибка должна использоваться только для диагностических сообщений», это означает, что, если не указано иное, диагностические сообщения должны отправляться на стандартную ошибку только тогда, когда состояние выхода указывает, что ошибка произошло, и утилита используется, как описано в этом томе POSIX.1-2008.

Если этот раздел указан как «Не используется», это означает, что стандартная ошибка не должна использоваться при использовании утилиты, как описано в этом томе POSIX.1-2008.

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

По принципу исключения, это может идти только в stderr. Да, я знаю, что вы спрашивали об официальной спецификации, которую я не могу представить вам помимо ссылки на спецификацию POSIX, предоставленную Стивеном Киттом, в которой говорится, что stderr предназначен для диагностических целей.

Более важным моментом является то, что stdin и stdout имеют функцию, которая запрещает печатать отчеты о ходе работ на stdout - они, конечно, образуют последовательность каналов, которая в командах оболочки Unix является не просто побочным эффектом, а самой основой мощного конвейерного подхода ,

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

Конечно, это оставляет дыру - было бы неплохо иметь «stdfluff» или что-то в этом роде, которое не предназначено ни для вывода, ни для ошибок, а для отчетов о проделанной работе, отладки и тому подобного. Фактически, ничто не мешает вам сделать это, то есть вы можете распечатать свой прогресс в файловом дескрипторе 3. Пример:

$ perl -e 'open($fd, ">", "/dev/fd/3"); print $fd "hello\n"'

Это не дает никакого выхода. (*)

$ perl -e 'open($fd, ">", "/dev/fd/3"); print $fd "hello\n"'  3>&1
hello

Это печатает на fd-3, который перенаправляется на стандартный вывод.

(*) Первый пример не производит вывода, но все еще немного надуман; openтерпит неудачу и $!будет содержать no such file or directory; просто возьмите это в качестве примера, конечно, не стоит так серьезно использовать. В реальной программе, если вы хотите пойти по этому пути, вы можете проверить, /dev/fd/3пригодно ли это для использования, и принять это как подсказку, активировать ли ваши отчеты о проделанной работе; вам придется сделать это довольно рано, чтобы вас не смущали ваши собственные openфайлы настоящих файлов и тому подобное ...

Сообщение об использовании должно идти в stdout, если пользователь вызвал его, --helpи в stderr, если они допустили ошибку. Безусловно, печатать его на stderr неприятно, потому что это затрудняет его просмотр с помощью пейджера / grep / и т.д.

Кроме того, могу я предложить третий способ: открыть / dev / tty для отчетов о проделанной работе / счетчиков / и т.д.