52

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

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

4

8 回答 8

53

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

于 2010-02-04T12:44:04.820 回答
8

我同意明确请求的“使用”（通过 -h、-? 或 --help 选项）应该转到标准输出，而为响应不正确的语法或其他错误而打印的“使用”应该转到标准错误。

但是，请注意，越来越流行的 popt 库（它处理命令行解析；它的名称代表“解析选项”）包括一个自动生成帮助的工具，并且它总是将它发送到 stderr。我引用 popt 手册页：

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

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

于 2012-01-10T21:23:27.817 回答
4

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

于 2010-02-04T12:36:25.897 回答
3

我会使用 STDERR，因为简单地将其放入 STDOUT 可能会导致管道输出出现问题，并且它会出现在 cronjobs 的日志中，因此您更容易注意到错误。

于 2010-02-04T12:37:43.093 回答
3

我总是被那些有很多选项不适合屏幕的程序所困扰，但是当运行 as 时program --help | less，我什么也看不到，因为帮助实际上已发送到stderr。

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

于 2016-04-19T01:24:38.617 回答
3

if --help then stdout, else stderr. Here's the JCommander code for Java users:

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);
}
于 2016-06-17T19:02:59.810 回答
2

在我看来，标准是信息如何出现。如果它需要立即反应或引起注意，我将其放入 stderr （因为它没有缓冲）。如果它以某种方式提供信息并且不考虑任何错误，则它适用于标准输出。

于 2010-02-04T12:37:10.400 回答
2

命令行“用法”应该打印在 stdout 还是 stderr 上？

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

浏览Java 代码约定（1997 年 9 月），Java 没有指定它。没有答案，将无休止地争论不休。

根据GNU 的编码标准，它应该打印在标准输出上：

4.7.2 --帮助

标准 --help 选项应该在标准输出上输出有关如何调用程序的简短文档，然后成功退出。一旦看到，其他选项和参数应该被忽略，并且程序不应该执行它的正常功能。

在 '--help' 选项输出的末尾附近，请放置提供错误报告的电子邮件地址的行，包的主页（通常是 '<a href="http://www.gnu.org/software/pkg" rel="nofollow noreferrer">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 选项应该指示程序在标准输出上打印有关其名称、版本、来源和法律状态的信息，然后成功退出。一旦看到，其他选项和参数应该被忽略，并且程序不应该执行它的正常功能。

第一行是为了便于程序解析；正确的版本号在最后一个空格之后开始。此外，它还包含该程序的规范名称，格式如下：

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.

...

于 2017-06-21T22:01:47.670 回答