我有一个应用程序可以将fprintf 的帮助和错误消息发送给stderr。
如果我以EXIT_SUCCESS 状态退出（例如当我向我的应用发出--help 选项时），我应该向stdout 发送消息吗？
同样，我应该继续在EXIT_FAILURE 上向stderr 发送错误消息吗？
或者我应该将所有帮助和错误消息发送到stdout？
对于符合 POSIX 的 UNIX 应用程序的一般约定是什么？
【问题讨论】：
标签： c posix stdout stderr printf
显然错误消息应该发送到stderr，因为您不想在重定向标准输出时捕获它们。
当由于某些命令行选项被无效使用而显示用法时，它会显示为（部分）错误消息。所以它应该转到stderr 并导致EXIT_FAILURE。
当由于用户通过--help 请求而显示用法时，它会显示为调用命令的所需行为。所以它应该转到stdout，并且该命令应该以EXIT_SUCCESS 成功。
GNU coding standards 对此进行了简要介绍。
【讨论】：
根据POSIX standard，标准错误用于写入诊断输出。他们似乎让应用程序来定义什么是诊断输出。
但是，在我看来，我不喜欢在stderr 上写帮助文本的应用程序，因为在文本上写一个简单的grep 更难。我会说这是 50/50，哪些程序这样做，哪些没有。
【讨论】：
stdout。
Posix 定义了标准流thus：
在程序启动时，应预定义三个流，无需显式打开：标准输入（用于读取常规输入），标准输出（用于编写常规输入）输出）和标准错误（用于写入诊断输出）。打开时，标准错误流没有完全缓冲；当且仅当可以确定流不引用交互式设备时，标准输入和标准输出流才会被完全缓冲。
GNU C Library 类似地描述了标准流：
变量：FILE * stdout
标准输出流，用于程序的正常输出。变量：FILE * stderr
标准错误流，用于程序发出的错误信息和诊断信息。
因此，除了“常规/正常输出”和“诊断/错误输出”之外，标准定义对流的使用几乎没有指导。在实践中，将这些流中的一个或两个重定向到文件和管道是很常见的，因此请考虑可能的用法。常规输出应发送至stdout，尤其是，如果用户可能会发送至grep 或以其他方式对其进行分析。特别是帮助文本应该转到stdout，以便可以轻松搜索和分页。一些系统监视stderr 的输出并将其视为问题的迹象，因此通常仅将其用于实际错误和其他重要诊断。最后，仅当流实际上是交互式的（例如，isatty 报告的）或通过命令行选项显式启用时才发送交互式输出（如进度指示器）。
【讨论】：
通过使用strace，您可以发现许多 GNU/Linux 实用程序（如 ls、date、gcc、make ...）将它们的 --help 输出到 stdout时间>。我建议像他们那样做。
【讨论】：