Должна ли командная строка «использование» печататься на stdout или stderr?

Question

При печати «использования» приложения, должно ли это быть сделано на stdout или на stderr?

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

Answer 1

Никогда не думал об этом, но почему бы не написать инструкции по использованию в stderr, если программа была вызвана без аргументов или без, и записать ее в stdout при вызове с --help (или аналогичным) аргументом? Таким образом, если использование показано из-за ошибки, оно переходит к stderr, а если это не ошибка из-за того, что пользователь запросил это, то оно переходит к stdout. Кажется логичным, как-то.

Answer 2

Я согласен, что явно запрашиваемое «использование» (через параметр -h, -? Или --help) должно переходить в стандартный вывод, а «использование» выводится в ответ на неправильный синтаксис или другие ошибки следует перейти к stderr.

Однако обратите внимание, что все более популярная библиотека popt (которая обрабатывает анализ командной строки; ее название обозначает «параметры разбора») включает в себя средство для автоматически сгенерированной справки и что она всегда отправляет ее в stderr. Я цитирую страницу руководства Popt:

Когда --usage или --help передаются программам, которые используют popt автоматическая справка, popt отображает соответствующее сообщение на stderr как как только он найдет опцию и выйдет из программы с кодом возврата 0.

Я считаю, что это ошибка popt, но проблема в том, что POSIX (или ISO C, к которому он относится) никогда не определял то, что имелось в виду под «диагностическим выводом». Просто прочитайте 'man stderr' или POSIX.1-2008 .

Answer 3

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

Answer 4

Меня всегда беспокоят программы, у которых много опций, которые не помещаются на экране, но когда я запускаю как program --help | less, я ничего не вижу, так как помощь фактически была отправлена ​​на stderr .

Мне нравится идея явно запрашиваемого использования (т. Е. Опция --help) должна отправлять вывод на stdout . В случае неверных опций, я думаю, что нет необходимости отображать подробную информацию об использовании. Определенно должно быть сообщение об ошибке типа Invalid option "--some-option". Run "program --help" for usage information., отправленное на stderr . Если программа решит выводить информацию об использовании по умолчанию для недопустимых опций или при ее вызове без опций, я думаю, что должно быть короткое сообщение об ошибке, сообщающее о недопустимом использовании, но сама справка может перейти к stdout .

Answer 5

Я бы использовал STDERR, поскольку простое помещение его в STDOUT может вызвать проблемы с конвейерным выводом, и оно будет отображаться в журналах для cronjobs, поэтому вы легче заметите ошибку.

Answer 6

если --help то стандартный вывод, иначе стандартный вывод. Вот код JCommander для пользователей Java:

MyOptions myOptions = new MyOptions();
JCommander jCommander = new JCommander(myOptions);

try {
    jCommander.parse(args);
} catch (ParameterException exp) {
    /* print the exp here if you want */
    StringBuilder sb = new StringBuilder();
    jCommander.usage(sb);
    System.err.println(sb.toString());
    System.exit(1);
}

if(myOptions.isHelp()) {
    jCommander.usage();
    System.exit(0);
}

Answer 7

По моему мнению, критерием является то, как появляется информация. Если это требует немедленной реакции или внимания, я помещаю это в stderr (потому что это небуферизовано). Если это как-то информативно и не учитывает никаких ошибок, это для stdout.

Answer 8

Должна ли командная строка «использование» печататься на stdout или stderr?

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

Просмотр Java CodeУсловные обозначения (SEPT 1997), Java не определяет его.Ответа нет, и он будет бесконечно обсуждаться.

Согласно стандартам кодирования GNU , он должен быть напечатан на стандартном выходе:

4.7.2 --help

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

В конце вывода параметра --help, пожалуйста, поместите строки, дающие адрес электронной почты для сообщения об ошибке.отчеты, домашняя страница пакета (обычно 'http://www.gnu.org/software/pkg’, и общая страница помощи по программам GNU. Формат должен быть таким:

Report bugs to: mailing-address
pkg home page: <http://www.gnu.org/software/pkg/>
General help using GNU software: <http://www.gnu.org/gethelp/>

Можно упомянуть другие соответствующие списки рассылкии веб-страницы.

---

Вот связанная с этим тема «версия» . Она также из руководства по кодированию GNU и также записывает в стандартный вывод:

4.7.1 --version

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

Первыйстрока предназначена для простого анализа программой;собственно номер версии начинается после последнего пробела.Кроме того, он содержит каноническое имя для этой программы в следующем формате:

GNU Emacs 19.30

Имя программы должно быть константной строкой;не вычисляйте это из argv [0].Идея состоит в том, чтобы указать стандартное или каноническое имя программы, а не имя файла.Существуют и другие способы узнать точное имя файла, в котором находится команда в PATH.

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

emacsserver (GNU Emacs) 19.30

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

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

Пожалуйста, не упоминайте все библиотеки, которые программа использует «только для полноты» - это может привести к бесполезному беспорядку.Пожалуйста, указывайте номера версий библиотеки только в том случае, если на практике вы обнаружите, что они очень важны для вас при отладке.

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

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

Можно завершить вывод списком основных авторов программы в качестве способа предоставления кредита.

Вот пример вывода, который следует за этимиправила:

GNU hello 2.3
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

...