我知道行为良好的实用程序，例如grep将“正常”消息输出到 stdout，将错误消息输出到 stderr。
$ grep '^foo' file1 file2
file1:foo
grep: file2: No such file or directory
当我自己编写 shell 脚本时，我经常发现很难决定应该在 stderr 上显示哪些输出和哪些消息，或者我是否应该打扰。
我想知道良好的做法：何时需要将某些消息重定向到 stderr 且合理，何时不合理？
当然，“这取决于情况”，但是您是否有一些见解可以帮助我做出这些决定？
为了使这个主观问题符合格式，我希望鼓励回答“为什么”，并以经验为基础，如果可能的话，以事实为依据。
答案1
当我自己编写 shell 脚本时，我经常发现很难决定应该在 stderr 上显示哪些输出和哪些消息，或者我是否应该打扰。
沉默是金。如果一切正常，则不输出任何内容。
我想知道良好的做法：何时需要将某些消息重定向到 stderr 且合理，何时不合理？
将 stderr 与 stdout 分开的最简单方法：想象一下所有脚本输出将通过管道重定向到另一个命令。在这种情况下，您应该将所有通知保留在 stderr 中，因为 stdout 中的此类意外信息可能会破坏管道顺序。
有时也出现在像这样的管道中：
command1 | while read line ; do command2 ; done | command3
您需要将某些内容传递command2给用户输出。没有临时文件的最简单方法是 stderr。
答案2
我通常将与应用程序操作相关的所有内容写入stderr，stdout为数据保留。
想象一个像cat.当您使用它读取输入并将其传递给另一个应用程序（通过管道）时，您不希望输出中充斥着状态消息。
另一个应用程序或我的应用程序的后处理器可能感兴趣的所有内容都将被删除stdout，仅与我的应用程序内部相关的所有内容都将被删除stderr。
答案3
我个人的偏好是将错误消息和异常stderr以及信息性消息发送到stdout。 IMO，stderr适用于任何例外情况，因此，这是我的惯例。