进度报告/记录信息是否属于stderr或stdout？

是否有正式的POSIX，GNU或其他指南，说明应在何处打印进度报告和日志记录信息（如“ Doing foo; foo done”之类的内容）？就个人而言，我倾向于将它们写入stderr，以便可以重定向stdout并仅获取程序的实际输出。最近有人告诉我，这不是一个好习惯，因为进度报告实际上不是错误，而应该仅将错误消息打印到stderr。

这两个职位都很有意义，当然您可以根据自己的工作细节选择一个或两个，但是我想知道是否有一个普遍接受的标准。在POSIX，GNU编码标准或任何其他这样的最佳实践列表中，我找不到任何特定的规则。

我们有一些类似的问题，但它们不能解决这个确切的问题：

• 何时在shell脚本中使用重定向到stderr：接受的答案表明了我倾向于做的事情，将程序的最终输出保留在stdout上，并保留给stderr。但是，尽管有论点支持，但这只是作为用户的意见而呈现的。

• 使用消息应该发送到stderr还是stdout？：这特定于帮助消息，但引用了GNU编码标准。这是我正在寻找的东西，不仅限于帮助消息。

那么，是否有关于打印进度报告和其他信息（不在程序实际输出中的部分）的官方规定？

Posix 因此定义了标准流：

在程序启动时，应预定义三个流，而不必明确打开它们：标准输入（用于读取常规输入），标准输出（用于写入常规输出）和标准错误（用于写入诊断输出）。打开时，标准错误流未完全缓冲；当且仅当可以确定该流不引用交互式设备时，标准输入流和标准输出流才被完全缓冲。

在GNU C库描述了同样的标准流：

变量：FILE * stdout
标准输出流，用于程序的常规输出。

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

因此，除了“常规/正常输出”和“诊断/错误输出”之外，标准定义对流的使用几乎没有指导。在实践中，通常将这两个流中的一个或两个都重定向到文件和管道，这会导致进度指示器出现问题。 。一些系统甚至监视 stderr输出，并认为这是问题的征兆。因此，在任何一个流上纯辅助进度信息都是有问题的。

重要的是要认识到进度输出仅适用于交互式流，而不是将进度指示器无条件地发送到任一标准流。考虑到这一点，我建议仅在检查流是否是交互式的（例如，使用）或由命令行选项显式启用后，才编写进度计数器。这对于依靠终端更新行为来理解进度表的进度表尤为重要，例如进度条％。isatty()

对于某些非常简单的进度消息（“开始X” ...“用X完成”），甚至对于非交互式流也包括输出是更合理的。在这种情况下，请考虑用户如何与流进行交互，例如使用进行搜索grep或分页，less或使用进行监视tail -f。如果在这些情况下查看进度消息是有意义的，那么从中将更容易使用它们stdout。

POSIX 将标准错误定义为

用于编写诊断输出

这不仅限于将其用于错误消息。我会将进度信息视为诊断输出，因此它属于标准错误。

POSIX在Shell and Utilities 1.4中对“诊断信息”的含义更为具体：实用程序描述默认值（强调我的）：

斯特德

STDERR部分描述了实用程序的标准错误输出。仅描述实用程序有意发送的那些消息。使用终端处理标准错误可能会导致在后台使用时，任何写入标准错误输出的标准实用程序都将停止。因此，应用程序不应在脚本中使用交互功能放置在后台。

对于大多数实用程序，诊断消息的格式未指定，但是此卷POSIX.1-2008未指定格式的诊断消息和信息消息的语言和文化惯例应受LC_MESSAGES和[XSI]设置的影响。 ] NLSPATH。[选项结束]

标准实用程序的指定标准错误输出应不依赖于POSIX.1-2008的本卷中定义的环境变量的存在或值，除非此POSIX.1-2008的卷中提供了环境变量。

默认行为：当本节被列为“标准错误应仅用于诊断消息。”时，这意味着，除非另有说明，否则仅当退出状态指示错误时，才将诊断消息发送为标准错误。发生了故障，并且如本POSIX.1-2008卷所述使用了该实用程序。

当本节被列为“未使用”时，表示按照本POSIX.1-2008卷中的说明使用实用程序时，不应使用标准错误。

IANASL，但我的解释是，仅当实用程序将返回错误退出代码时，stderr才会输出。由于这不应该是成功执行事件的正常过程，因此除非出现错误（除非除非另外指定，否则），否则POSIX实用程序不应打印任何进度信息。

根据排除的原则，它只能进入stderr。是的，我知道您问过一个正式的规范，除了Stephen Kitt给出的指向POSIX规范的链接之外，我无法向您介绍它，该声明指出stderr用于诊断。

更重要的一点是stdin和stdout具有不允许将进度报告打印到stdout的功能-它们当然形成了管道序列，在Unix shell命令中这不仅是副作用，而且是强大的流水线方法的核心。

所以。程序的真正“有效负载”不属于stdout。如果您的程序没有输出，那么什么都不应该进入标准输出。这使得标准错误的一切，包括进度报告。

当然，这留下了一个漏洞-最好有一个“ stdfluff”或类似的东西，既不是输出也不是错误，而是用于进度报告，调试等。实际上，没有什么可以阻止您执行此操作，即可以将进度打印到文件描述符3中。示例：

$ perl -e 'open($fd, ">", "/dev/fd/3"); print $fd "hello\n"'

这不会产生任何输出。（*）

$ perl -e 'open($fd, ">", "/dev/fd/3"); print $fd "hello\n"'  3>&1
hello

这将打印到fd-3，该文件将重定向到stdout。

（*）第一个示例不产生任何输出，但仍然有些牵强。的open失败，$!将包含no such file or directory; 仅以此为例，认真使用这种方式当然是不重要的。在实际程序中，如果您想走这条路，则可以测试是否/dev/fd/3可用，并以此作为是否激活进度报告的提示。您必须尽早这样做，以免您自己open对真实文件等感到困惑。

如果用户使用了该用法消息，则应该将其发送到stdout；如果用户输入--help了错误，则应将其发送到stderr。无条件地将其打印到stderr是令人讨厌的，因为这使使用pager / grep / etc进行查看变得更加困难。

另外，我可以建议第三种方法：打开/ dev / tty获取进度报告/ spinners / etc。