Question

打印应用程序的“用法”时，是应该在stdout还是stderr上完成？

根据应用程序，我看过几个案例，但似乎没有一个规则。也许我错了，有一个很好的做法。在那种情况下，它是什么？

Answer 1

没想过，但是如果用无参数或错误的参数调用程序，为什么不将使用说明写入stderr，并在用--help（或类似）参数调用时将其写入stdout？这样，如果由于错误而显示用法，则转到stderr，如果由于用户请求它而不是错误，则转到stdout。似乎是合乎逻辑的，不知怎的。

Answer 2

我同意显式请求“使用”（通过-h， - ？或--help选项）应该转到stdout，同时打印“usage”以响应不正确的语法或其他错误应该发送到stderr。

但请注意，越来越流行的popt库（处理命令行解析;其名称代表“解析选项”）包括自动生成帮助的工具，始终将其发送给stderr 。我引用popt手册页：

当--usage或--help传递给使用popt的程序时自动帮助，popt在stderr上显示相应的消息一旦找到该选项，并退出程序返回代码 0。

我认为这是一个popt bug，但问题是POSIX（或它推迟的ISO C）从未定义“诊断输出”的含义。只需阅读'man stderr'或POSIX.1-2008。

Answer 3

这只能是意见，但我认为写给stderr是最好的办法。这样，即使正常输出已被重定向，如果用户犯了错误，也会显示使用消息。

Answer 4

我使用STDERR，因为简单地将它放到STDOUT可能会导致管道输出出现问题，它会出现在cronjobs的日志中，所以你会发现错误更容易。

Answer 5

我总是被有很多选项不适合屏幕的程序所困扰，但是当我以program --help | less运行时，我无法看到任何内容，因为帮助是实际上发送到 stderr 。

我喜欢明确请求使用的想法（即--help选项）应该将输出发送到 stdout 。如果选项无效，我认为没有必要显示详细的使用信息。肯定应该有一个错误消息，例如发送到 stderr 的Invalid option "--some-option". Run "program --help" for usage information.。如果程序决定默认输出无效选项的使用信息，或者在没有选项的情况下调用，我认为应该有一条简短的错误消息抱怨无效使用，但帮助本身可能会转到 stdout 。 / p>

Answer 6

据我所知，标准是信息的出现。如果它需要立即反应或注意，我把它放入stderr（因为它没有缓冲）。如果它在某种程度上提供了信息，并且不会将任何错误视为stdout。

Answer 7

如果--help那么stdout，否则stderr。这是Java用户的JCommander代码：

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 8

是否应在stdout或stderr上打印命令行“usage”？

我认为这取决于组织的编码标准。在一个组织之外，它可能是那些无休止争论的主题之一，比如哪个是最好的操作系统，这是最好的编辑，这是正确的宗教，......

浏览Java Code Conventions（SEPT 1997），Java没有指定它。没有答案，这将是无休止的争论。

根据GNU's coding standards，它应该打印在标准输出上：

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/>
可以提及其他适当的邮件列表和网页。

以下是＆＃34;版本＆＃34; 的相关主题。它也来自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.
...

是否应在stdout或stderr上打印命令行“usage”？

8 个答案: