何时使用系统标准输出而不是系统标准？

Question

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

这个节目是一种服务。它发送给stderr的一些消息是：

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

所以这是一个输出，对吗？关于成功与否的消息应该发送到stdout，因为这不是一个错误？在

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

^{pr2}$

这是一个例外，所以应该转到stderr，因为这是一个错误？或者应该转到stdout，因为它是一条输出消息，只是说程序失败了？在

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

这两个示例都是错误消息，但其中一个只是“程序未运行”。我很难选择这种信息应该发送到哪里。在

Answer 1

致命的错误当然应该归stderr所有。正常输出应转到stdout。在

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

你需要决定哪个部门最有意义。在

Answer 2

Tom Karzes已经给了你一个正确的答案，但是为了说明一个更极端的立场。。。在

我发现把stdout和{}看作“标准输出”和“标准非输出”是有帮助的。您说过您认为消息“应该转到stdout，因为这不是一个错误”，但这是反向的：stdout是具有高进入壁垒的流，而不是stderr。在

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

很有可能的是，你的用户没有运行你的程序，因为他们想看一个旋转的指挥棒，或者阅读十几条“试图重新连接…”的消息，甚至是想知道哪些fork失败了，所以那些应该是而不是打开的stdout。在

最后，有些消息不应该转到或输出流。stderr可能是由用户读取的，所以请尝试将其输出限制为用户现在关心的内容。保持它不受“情况正常”消息的影响，除非用户通过打开详细信息（通常是 verbose或{}）明确请求它们。至少允许用户使用 quiet或 silent选项使非错误静音。大多数“信息性”消息应该发送到日志文件，而不是控制台。在