何时使用 sys.stdout 而不是 sys.stderr？

Question

我的老板让我查看一些旧代码，其中所有内容都发送到 stderr。我知道 stderr 应该有警告和错误，但是什么时候他们真的应该去 stdout 呢？

此程序是一项服务。它发送到 stderr 的一些消息是：

if pid is None:
    message = "pidfile {0} is not running. \n"
    sys.stderr.write(message.format(self.pidfile))

所以这是一个输出，对吧？关于成功与否的消息应该转到标准输出，因为这不是错误？

然后我又得到了一个例外：

except OSError as err:
    sys.stderr.write('fork #1 failed: {0}\n'.format(err))
    sys.exit(1)

这个作为一个例外，所以应该去stderr，因为它是一个错误？还是应该去stdout，因为它只是说程序失败的输出消息？

我知道 stdout 和 stderr 是什么 --- 在问之前我读了很多。我的问题是能够识别 哪些 消息应该发送到 stderr --- 只是致命错误，还是任何类型的错误消息？

这两个示例都是错误消息，但其中一个只是“程序未运行”。我无法选择应将此类消息发送到何处。

Answer 1

Tom Karzes已经给你一个正确的答案，但要陈述一个更极端的立场......

我发现将stdout 和stderr 视为“标准输出”和“标准非输出”会有所帮助。你说你认为一条消息“应该转到stdout，因为它不是错误”，但那是倒退的：stdout 是进入门槛很高的流，而不是stderr。

一条消息应该发送到stderr（或日志文件，或除stdout 之外的任何内容），除非它可证明是所需输出的一部分 --- 用户实际想要的最终产品。如果你不能用“用户要求...”开头的句子来证明它的包含是合理的，不要用它污染stdout。 （管道中的下一个流程将感谢您。）

很可能，您的用户没有运行您的程序，因为他们想看一个旋转的指挥棒，或者阅读一打“尝试重新连接...”消息，甚至想了解哪些分叉失败了，所以这些应该不在stdout。

最后，一些消息不应该发送到任何一个输出流。 stderr 可能正在被用户阅读，因此请尝试将其输出限制为用户现在关心的内容。保持它没有“情况正常”消息，除非用户通过提高详细程度（通常是--verbose 或--debug）特别要求它们。至少允许用户使用--quiet 或--silent 选项使非错误静音。大多数“信息性”消息应该发送到日志文件而不是控制台。

Answer 2

致命错误当然应该转到 stderr。正常输出应该到标准输出。

信息性消息有一个灰色区域，但一般来说，如果它们会使输出不可用，它们不应该转到标准输出。人们通常会将 stdout 指向文件，将 stderr 指向终端或日志文件。

您需要决定哪种划分最有意义。