進捗レポート/ログ情報はstderrまたはstdoutに属しますか？

進捗レポートとログ情報（「Doing foo; foo done」など）を印刷する場所に関する公式のPOSIX、GNU、またはその他のガイドラインはありますか？個人的には、標準エラー出力にリダイレクトして、プログラムの実際の出力のみを取得できるように、標準エラー出力に書き込む傾向があります。最近、進捗レポートは実際にはエラーではなく、エラーメッセージのみがstderrに出力されるため、これは良い方法ではないと言われました。

両方のポジションが理にかなっており、もちろん、あなたがしていることの詳細に応じてどちらかを選択することができますが、これについて一般的に受け入れられている標準があるかどうか知りたいです。POSIX、GNUコーディング標準、またはその他の広く受け入れられているベストプラクティスのリストに特定のルールを見つけることができませんでした。

同様の質問がいくつかありますが、これらは正確な問題に対処していません。

• シェルスクリプトでstderrへのリダイレクトを使用する場合：受け入れられた答えは、私がする傾向があることを示唆しています。ただし、これはユーザーの意見として提示されていますが、引数によってサポートされています。

• 使用法メッセージはstderrまたはstdoutに送信する必要がありますか？：これはヘルプメッセージに固有ですが、GNUコーディング標準を引用しています。これは私が探している種類のもので、ヘルプメッセージだけに制限されていません。

それでは、進捗レポートやその他の情報メッセージ（プログラムの実際の出力の一部ではない）を印刷する場所に関する公式ルールはありますか？

Posixは標準ストリームを次のように定義します：

プログラムの起動時に、標準入力（従来の入力を読み取るため）、標準出力（従来の出力を書き込むため）、および標準エラー（診断出力を書き込むため）の3つのストリームを事前に定義し、明示的に開く必要はありません。開いたとき、標準エラーストリームは完全にバッファリングされていません。ストリームが対話型デバイスを参照しないと判断できる場合にのみ、標準入力および標準出力ストリームは完全にバッファリングされます。

GNU Cライブラリは、同様に標準ストリームについて説明します。

変数：FILE * stdout
プログラムからの通常の出力に使用される標準出力ストリーム。

変数：FILE * stderr
標準エラーストリーム。プログラムによって発行されるエラーメッセージと診断に使用されます。

したがって、標準の定義では、「従来の/通常の出力」と「診断/エラーの出力」以外のストリームの使用に関するガイダンスはほとんどありません。 。一部のシステムは、出力を監視 stderrし、問題の兆候と見なします。したがって、純粋に補助的な進行情報は、どちらのストリームでも問題があります。

代わりに無条件で進行状況インジケーターを送信するいずれかの標準的な流れ、それが進歩出力がためにのみ適切であることを認識することが重要ですインタラクティブストリーム。それを念頭に置いて、ストリームが対話型（たとえば、isatty()）であるかどうかを確認した後、またはコマンドラインオプションで明示的に有効にした場合にのみ、進行状況カウンターを記述することをお勧めします。これは、％完了バーのように、端末更新の動作に依存して進行するメーターにとって特に重要です。

特定の非常に単純な進行メッセージ（「Starting X」...「Done with X」）の場合、非インタラクティブストリームの場合でも出力を含める方が合理的です。その場合は、での検索、grepページング、lessまたは監視など、ユーザーがストリームと対話する方法を検討してくださいtail -f。これらのコンテキストで進行メッセージを表示するのが理にかなっている場合は、から消費するのがはるかに簡単になりますstdout。

POSIX は標準エラーを次のように定義します

診断出力を書き込むため

これは、エラーメッセージのみに使用を制限するものではありません。進捗情報を診断出力と見なすため、標準エラーに属します。

POSIXは、Shell and Utilitiesの「診断情報」、1.4：Utility Description Defaults（emphasis mine）についてもう少し具体的です。

STDERR

STDERRセクションでは、ユーティリティの標準エラー出力について説明しています。ユーティリティによって意図的に送信されるメッセージのみが説明されています。標準エラー用の端末を使用すると、標準エラー出力を書き込む標準ユーティリティがバックグラウンドで使用されると停止する場合があります。このため、アプリケーションは、スクリプトでインタラクティブ機能を使用してバックグラウンドに配置しないでください。

ほとんどのユーティリティの診断メッセージの形式は指定されていませんが、POSIX.1-2008のこのボリュームで形式が指定されていない診断および情報メッセージの言語および文化的慣習は、LC_MESSAGESおよび[XSI] [Option Start ] NLSPATH。[オプション終了]

標準ユーティリティの指定された標準エラー出力は、このPOSIX.1-2008のボリュームで提供されている場合を除き、このPOSIX.1-2008のボリュームで定義されている環境変数の存在または値に依存してはなりません。

デフォルトの動作：このセクションが「標準エラーは診断メッセージにのみ使用される」と記載されている場合、特に明記しない限り、終了ステータスがエラーを示す場合にのみ診断メッセージが標準エラーに送信されることを意味します発生したとPOSIX.1-2008のこの体積により記載されるようにユーティリティが使用されています。

このセクションが「使用しない」と表示されている場合、POSIX.1-2008のこのボリュームで説明されているようにユーティリティを使用する場合、標準エラーを使用しないことを意味します。

IANASLですが、ユーティリティがエラー終了コードを返す場合にのみstderrが出力することを意味すると解釈します。これは正常に実行されるための通常のイベントではないため、エラーが発生しない限り、POSIXユーティリティは進捗情報を出力しません（もちろん、特に指定がない限り）。

除外の原則により、stderrにのみ移動できます。はい、私はあなたが公式仕様について尋ねたのを知っています、stderrは診断目的のためであると述べるStephen Kittによって与えられたPOSIX仕様へのリンクを超えてあなたに提示することはできません。

より重要な点は、stdinおよびstdoutには、stdoutへの進行状況レポートの印刷を許可しない機能があることです。もちろん、Unixシェルコマンドでは単なる副作用ではなく、強力なパイプライニングアプローチのコアであるパイプのシーケンスを形成します。

そう。プログラムの実際の「ペイロード」以外は、stdoutに属しません。プログラムに出力がない場合、何も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に無条件に印刷すると、ページャー/ grep / etcで表示するのが難しくなるため、不快です。

また、3つ目の方法を提案できます。/dev/ttyを開いて、進捗レポート/スピンナー/などを確認します。