進捗レポートとログ情報（「Doingfoo; foodone」など）を印刷する場所に関する公式のPOSIX、GNU、またはその他のガイドラインはありますか？個人的には、stdoutをリダイレクトして、プログラムの実際の出力のみを取得できるように、それらをstderrに書き込む傾向があります。最近、進捗レポートは実際にはエラーではなく、エラーメッセージのみをstderrに出力する必要があるため、これは適切な方法ではないと言われました。
どちらの立場も理にかなっており、もちろん、自分がしていることの詳細に応じてどちらかを選択できますが、これについて一般的に受け入れられている基準があるかどうかを知りたいと思います。 POSIX、GNUコーディング標準、またはその他の広く受け入れられているベストプラクティスのリストで特定のルールを見つけることができませんでした。
同様の質問がいくつかありますが、これらはこの正確な問題に対処していません：
-
シェルスクリプトでstderrへのリダイレクトを使用する場合：受け入れられた回答は、私が何をする傾向があるかを示唆しており、プログラムの最終出力をstdoutおよびその他のstderrに保持します。ただし、これは、議論によって裏付けられているものの、ユーザーの意見として提示されているだけです。
-
使用法メッセージはstderrまたはstdoutに送信する必要がありますか？：これはヘルプメッセージに固有ですが、GNUコーディング標準を引用しています。これは私が探している種類のものであり、ヘルプメッセージのみに限定されません。
それで、進捗レポートやその他の有益なメッセージ（プログラムの実際の出力の一部ではない）をどこに印刷するかについての公式の規則はありますか？
承認された回答：
Posixは、標準ストリームを次のように定義しています。
プログラムの起動時に、3つのストリームが事前定義されている必要があり、明示的に開く必要はありません。標準入力 （従来の入力を読み取るため）、標準出力 （従来の出力を書き込むため）、および標準エラー （診断出力の書き込み用）。開いたとき、標準エラーストリームは完全にバッファリングされていません。標準入力ストリームと標準出力ストリームは、ストリームが対話型デバイスを参照していないと判断できる場合にのみ、完全にバッファリングされます。
GNU Cライブラリは、標準ストリームについても同様に説明しています。
変数：ファイル * stdout
プログラムからの通常の出力に使用される標準出力ストリーム。変数：ファイル * stderr
プログラムによって発行されるエラーメッセージと診断に使用される標準エラーストリーム。
したがって、標準の定義には、「従来の/通常の出力」および「診断/エラーの出力」以外のストリームの使用に関するガイダンスはほとんどありません。実際には、これらのストリームのいずれかまたは両方をファイルとパイプラインにリダイレクトするのが一般的です。進行状況インジケーターが問題になります。一部のシステムはモニター stderr 出力のために、それを問題の兆候と考えてください。したがって、純粋に補助的な進捗情報は、どちらのストリームでも問題があります。
進行状況インジケーターを無条件にどちらかに送信する代わりに 標準ストリームの場合、進行状況の出力はインタラクティブにのみ適切であることを認識することが重要です。 ストリーム。そのことを念頭に置いて、ストリームがインタラクティブであるかどうかを確認した後でのみ、進行状況カウンターを作成することをお勧めします（たとえば、isatty() ）またはコマンドラインオプションで明示的に有効にした場合。これは、％-completeバーのように、端末の更新動作に依存して意味をなすプログレスメーターにとって特に重要です。
特定の非常に単純な進行状況メッセージ（「StartingX」…「Donewith X」）の場合、非対話型ストリームの場合でも出力を含める方が合理的です。その場合、grepで検索するなど、ユーザーがストリームをどのように操作するかを検討してください。 またはlessでページングする またはtail -fで監視する 。これらのコンテキストで進行状況メッセージを表示することが理にかなっている場合は、stdoutからの進行状況メッセージをはるかに簡単に利用できます。 。