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

Question

我有一个应用fprintf向stderr提供帮助和错误消息。

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

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

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

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

Answer 1

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

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

当显示用法因为用户通过--help请求它时，它显示为调用命令所需的行为。所以它应该转到stdout，命令应该以{{1​​}}成功。

GNU coding standards中简要介绍了这一点。

Answer 2

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

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

Answer 3

Posix定义标准流thus：

  

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

GNU C Library同样描述了标准流：

  

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

     

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

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

Answer 4

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