Подтвердить что ты не робот

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

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

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

4b9b3361

Ответ 1

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

Ответ 2

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

Однако обратите внимание, что все более популярная popt-библиотека (которая обрабатывает синтаксический анализ командной строки, ее имя означает "параметры анализа" ) включает средство для автоматической сгенерированной справки и что он всегда отправляет это в stderr, Я цитирую страницу popt man:

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

Ответ 6

if --help then stdout, else stderr. Здесь код 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);
}

Ответ 7

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

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

Ответ 8

В случае, если "использование" командной строки должно быть напечатано на stdout или stderr?

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

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

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

4.7.2 --help

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

В конце вывода "-help options" поместите строки предоставление адреса электронной почты для отчетов об ошибках, домашняя страница пакетов (обычно 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.

...