私はそれをさまざまな方法で見てstdout使用stderrしました。私が知る限り、それは一般的にstdout一般的な情報やstderrエラーなどに使用されます。ただし、stderrプログラム自体に関する情報（エラー、警告、デバッグなどとは関係ありません）を出力し、デバッグ目的で使用することもあります（後者がフィルタリングできるようにエラーストリームを使用すると仮定します）。デバッグ）とstdout含めるべきだと思うより深刻な警告がありますstderr。
stdoutもしそうなら、これが理想的な使用と見なされるか、stderr一般的な出力とエラーに加えて、プログラム出力に関連するのはいつであるか疑問に思います。プログラムに依存していますか、それとも一般的ですか？
答え1
とを分離する理由は、まずstdoutプログラムデータ出力（ファイルに保存したりパイプなどに供給することができる）と診断と毛羽立ち（stderr端末の人間オペレータだけに興味がある）を区別するためです。 。 （入力に対して同じことを行う自動方法はありませんが、stdin代わりに制御端末デバイスを開いて読み取る方法でいくつかの問題を経験して実行できます。）stdoutあります。）stderr2>&1bash
答え2
時々違うよ！関連要因は、stderr障害が発生したときにエラーメッセージがバッファに解放されることを望まないため、デフォルトはバッファリングされないことです。一方、stdoutデフォルト値はライン（ターミナル）またはブロック（そうでない場合）バッファリングされます。エラーはデータ行またはブロックを失う可能性がありますが、このアプローチはより効率的です。もう一つは、プログラムが出力することです。何かがCSVやJSONなどの特定の形式をエクスポートしている場合は、エラーメッセージを混在させるとプログラムが破損する可能性があります（または特定の形式にエンコードする必要があり、その形式の場合）。 abort! abort! ）、他の場合（対話型メニュータイプシステム？）エラーメッセージを他の出力と混在させることはそれほど重要ではありません。
答え3
誰かがある時点であなたのプログラムをパイプラインに入れると常に考えてください。
$ inputProducer | yourProgram | outputConsumer
stderrまたはに何かをターゲティングするかを検討する際にstdout重要なのは、コンテンツが（一般的に）関連性があるのかoutputConsumer、それともそれがあなたの人生をより困難にするのかということです。
- 関連:
stdout - 無関係：
stderr
（より良いオプションにもかかわらず、人々がリダイレクトするのを忘れたため、多くのバグレポートが代わりに移動するstdoutことに注意してください。）stderrstderr