何时使用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))

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

然后我得到另一个例外：

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

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

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

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

Answer 1

应该发生致命错误。 正常输出应该转到stdout。

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

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

Answer 2

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

我发现将stdout和stderr视为“标准输出”和“标准非输出”是有帮助的。 你说你认为一条消息“应该去stdout因为它不是一个错误”，但那是向后的： stdout是具有高进入门槛的流，而不是stderr 。

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

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

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