当前位置：文江博客话题详情

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

发布于 2024-08-19 22:03:09 字数 109 浏览 7 评论 0原文

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

根据应用程序的不同，我见过几种情况，但似乎没有一个规则。也许我错了，有一种好的做法。既然如此，那又是什么呢？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

长亭外，古道边 2024-08-26 22:03:10

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

回复收藏 0 原文

ˉ厌 2024-08-26 22:03:10

如果 --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);
}

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);
}

回复收藏 0 原文

老娘不死你永远是小三 2024-08-26 22:03:10

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

回复收藏 0 原文

微暖i 2024-08-26 22:03:10

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

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

在组织之外，这可能是 oracle.com/technetwork/java/codeconventions-150003.pdf" rel="nofollow noreferrer">Java 代码约定（1997 年 9 月），Java 没有指定它。没有答案，人们会无休止地争论。

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

4.7.2 --help
标准的 --help 选项应该输出关于如何操作的简短文档
在标准输出上调用程序，然后成功退出。
一旦看到这种情况，其他选项和参数就应该被忽略，并且
该程序不应执行其正常功能。
在“--help”选项输出的末尾附近，请放置几行
提供错误报告的电子邮件地址、包的主页
（通常是“http://www.gnu.org/software/pkg”，并且一般页面
帮助使用 GNU 程序。格式应该是这样的：
将错误报告至：mailing-address
pkg 主页：
使用 GNU 软件的一般帮助：
可以提及其他适当的邮件列表和网页。

这是“版本”的相关主题。它也来自 GNU 编码指南，并且也写入标准输出：

4.7.1 --版本
标准的 --version 选项应指示程序进行打印
有关其名称、版本、起源和法律状态的信息，全部在
标准输出，然后成功退出。其他选项和
一旦看到这种情况，就应该忽略参数，并且程序应该
无法执行其正常功能。
第一行是为了便于程序解析；版本
正确的数字在最后一个空格之后开始。此外，它还包含
该程序的规范名称，格式如下：
<前><代码>GNU Emacs 19.30
程序的名称应该是一个常量字符串；不要计算它
argv[0]。这个想法是陈述标准或规范名称
程序，而不是其文件名。还有其他方法可以查到
在 PATH 中找到命令的精确文件名。
如果该程序是较大程序包的附属部分，请提及
括号中的包名称，如下所示：
emacsserver (GNU Emacs) 19.30
如果软件包的版本号与此不同
程序的版本号，可以提及包的版本号
就在右括号之前。
如果您需要提及库的版本号
与包含该程序的包分开分发，
您可以通过为每个版本打印一行附加的版本信息来做到这一点
你想提及的图书馆。对这些行使用相同的格式
对于第一行。
请不要提及该程序使用的所有库“只是
为了完整性”——这会产生很多无用的混乱。
仅当您在实践中发现时才请提及库版本号
它们对于您的调试非常重要。
版本号行之后的以下行应该是
版权声明。如果需要多个版权声明，
将每个内容放在单独的行上。
接下来应该遵循一行说明许可证，最好使用以下之一
下面的缩写以及该程序免费的简短声明
软件，并且用户可以自由复制和更改它。还提到
在法律允许的范围内，不提供任何保证。看
下面推荐的措辞。
可以用主要作者的列表来完成输出
计划，作为给予信用的一种方式。
以下是遵循这些规则的输出示例：
<前><代码>GNU 你好2.3
版权所有 (C) 2007 自由软件基金会, Inc.
许可证 GPLv3+：GNU GPL 版本 3 或更高版本
这是免费软件：您可以自由更改和重新分发它。
在法律允许的范围内，不提供任何保证。
...

Should the command line “usage” be printed on stdout or stderr?

I think it depends on the organization's coding standards. Outside an organization, its probably one of those topics that are endlessly debated, like which is the best operating system, which is the best editor, which is the right religion, ...

Browsing Java Code Conventions (SEPT 1997), Java does not specify it. There is no answer, and it will be endlessly debated.

According to GNU's coding standards, it should be printed on standard output:

4.7.2 --help
The standard --help option should output brief documentation for how
to invoke the program, on standard output, then exit successfully.
Other options and arguments should be ignored once this is seen, and
the program should not perform its normal function.
Near the end of the ‘--help’ option’s output, please place lines
giving the email address for bug reports, the package’s home page
(normally ‘http://www.gnu.org/software/pkg’, and the general page for
help using GNU programs. The format should be like this:
Report bugs to: mailing-address
pkg home page: <http://www.gnu.org/software/pkg/>
General help using GNU software: <http://www.gnu.org/gethelp/>
It is ok to mention other appropriate mailing lists and web pages.

Here's the related topic of "version". Its also from the GNU coding guide, and it also writes to standard output:

4.7.1 --version
The standard --version option should direct the program to print
information about its name, version, origin and legal status, all on
standard output, and then exit successfully. Other options and
arguments should be ignored once this is seen, and the program should
not perform its normal function.
The first line is meant to be easy for a program to parse; the version
number proper starts after the last space. In addition, it contains
the canonical name for this program, in this format:
GNU Emacs 19.30
The program’s name should be a constant string; don’t compute it from
argv[0]. The idea is to state the standard or canonical name for the
program, not its file name. There are other ways to find out the
precise file name where a command is found in PATH.
If the program is a subsidiary part of a larger package, mention the
package name in parentheses, like this:
emacsserver (GNU Emacs) 19.30
If the package has a version number which is different from this
program’s version number, you can mention the package version number
just before the close-parenthesis.
If you need to mention the version numbers of libraries which are
distributed separately from the package which contains this program,
you can do so by printing an additional line of version info for each
library you want to mention. Use the same format for these lines as
for the first line.
Please do not mention all of the libraries that the program uses “just
for completeness”—that would produce a lot of unhelpful clutter.
Please mention library version numbers only if you find in practice
that they are very important to you in debugging.
The following line, after the version number line or lines, should be
a copyright notice. If more than one copyright notice is called for,
put each on a separate line.
Next should follow a line stating the license, preferably using one of
abbreviations below, and a brief statement that the program is free
software, and that users are free to copy and change it. Also mention
that there is no warranty, to the extent permitted by law. See
recommended wording below.
It is ok to finish the output with a list of the major authors of the
program, as a way of giving credit.
Here’s an example of output that follows these rules:
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.
...

回复收藏 0 原文

宣告ˉ结束 2024-08-26 22:03:09

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

回复收藏 0 原文

吃不饱 2024-08-26 22:03:09

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

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

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

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

回复收藏 0 原文

怀念你的温柔 2024-08-26 22:03:09

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

回复收藏 0 原文

机场等船 2024-08-26 22:03:09

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

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