stdout / stderr消息的约定是什么？

Question

我有一个应用程序，将fprintf既帮助和错误消息到stderr 。

如果我退出状态EXIT_SUCCESS （例如当我向我的应用程序发出--help选项时），我应该向stdout发送消息吗？

同样，我应该继续在EXIT_FAILURE上向stderr发送错误消息吗？

或者我应该向stdout发送所有帮助和错误消息？

符合POSIX标准的UNIX应用程序的一般约定是什么？

Answer 1

显然错误消息应该转到stderr ，因为在重定向标准输出时你不想捕获它们。

当显示用法因为某些命令行选项被无效使用时，它将显示为（部分）错误消息。 所以应该去stderr并导致EXIT_FAILURE 。

当显示用法时，因为用户通过--help请求它，然后它被显示为调用命令的所需行为。 所以它应该转到stdout ，命令应该成功使用EXIT_SUCCESS 。

GNU编码标准简要介绍了这一点。

Answer 2

根据POSIX标准 ， 标准错误用于写入诊断输出 。 他们似乎将其留给应用程序来定义什么是诊断输出 。

然而，在我不那么谦虚的意见中，我不喜欢在stderr上写下他们的帮助文本的应用程序，因为在文本上做一个简单的grep更难。 我会说它是50/50，哪些程序执行此操作，哪些不执行此操作。

Answer 3

POSIX定义标准流从而 ：

在程序启动时，应预定义三个流，无需明确打开： 标准输入 （用于读取传统输入）， 标准输出 （用于写入常规输出）和标准错误 （用于写入诊断输出）。 打开时，标准错误流未完全缓冲; 当且仅当可以确定流不参考交互设备时，标准输入和标准输出流被完全缓冲。

GNU C库类似地描述了标准流：

变量： FILE * 标准输出
标准输出流，用于程序的正常输出。

变量： FILE * stderr
标准错误流，用于程序发出的错误消息和诊断。

因此，标准定义对“常规/正常输出”和“诊断/错误输出”之外的流使用几乎没有指导。实际上，将这些流中的一个或两个重定向到文件和管道是很常见的，因此请考虑可能的用法。 常规输出应该转到stdout ， 特别是如果用户可能会grep或以其他方式分析它。 特别是帮助文本应该转到stdout以便可以轻松搜索和分页。 有些系统监视stderr的输出并将其视为问题的标志，因此通常仅将其用于实际错误和其他重要诊断。 最后，如果流实际上是交互式的（例如，由isatty报告）或者通过命令行选项显式启用，则仅发送交互式输出（如进度指示器）。

Answer 4

通过使用strace您可以发现许多GNU / Linux实用程序（如ls ， date ， gcc ， make ...）将--help输出到stdout 。 我建议他们这样做。