シェルスクリプトでstderrへのリダイレクトを使用する場合

grepのような行儀の良いユーティリティは、stdoutに「通常の」メッセージを、stderrにエラーメッセージを出力することを知っています。

$ grep '^foo' file1 file2
file1:foo
grep: file2: No such file or directory

シェルスクリプトを自分で書いているとき、stderrにどの出力とメッセージを表示するか、または気にする必要があるかどうかを判断するのが難しいことがよくあります。

私は良い習慣について知りたいです：いつメッセージをstderrにリダイレクトするのが適切であり、そうでないのか？

「依存します」は確かですが、これらの決定を下すのに役立つ洞察はありますか？

この主観的な質問を形式に合うようにするために、「なぜ」に対処し、経験と可能であれば事実に裏打ちされた情報が得られる答えを奨励したいと思います。

シェルスクリプトを自分で書いているとき、stderrにどの出力とメッセージを表示するか、または気にする必要があるかどうかを判断するのが難しいことがよくあります。

沈黙は金なり。すべてが正常であれば、何も出力しません。

私は良い習慣について知りたいです：いつメッセージをstderrにリダイレクトするのが適切であり、そうでないのか？

stderrをstdoutから分離する最も簡単な方法：すべてのスクリプト出力がパイプ経由で別のコマンドにリダイレクトされることを想像してください。その場合、すべての通知をstderrに保持する必要があります。stdoutのこのような予期しない情報により、パイプシーケンスが中断される可能性があるためです。

また、このようなパイプでは時々：

command1 | while read line ; do command2 ; done | command3

command2ユーザー出力に何かを渡す必要があります。一時ファイルを使用しない最も簡単な方法は、stderrです。

Iするアプリケーションの操作に関連する一般的書き込みはすべてstderr、stdoutデータ用に予約されています。

のようなアプリケーションを想像してくださいcat。これを使用して入力を読み取り、（パイプを介して）別のアプリケーションに渡す場合、出力にステータスメッセージが散らばらないようにする必要があります。

別のアプリケーションや私のアプリケーションのポストプロセッサーにとって興味深いかもしれないものはstdoutすべて、私のアプリケーションの内部にのみ関連するものはすべてしようとしているstderr。

私の個人的な好みは、エラーメッセージと例外を通知メッセージに送信stderrすることstdoutです。IMO stderrは例外のためであり、したがって、私の慣例です。