web-dev-qa-db-ja.com

警告やエラーが発生したときにプログラム名を出力する必要がありますか？

スクリプトまたはプログラムを作成している場合、警告またはエラーメッセージとともにその名前をstderrに出力する必要がありますか？例えば：

./script.sh: Warning! Variable "var" lowered down to 10.

または：

./prog.py: Error! No such file: "file.cfg".

一般的には好みの問題だと理解していますが（特に自分で自分で書いた場合）、それに慣習的なものはあるのでしょうか。ほとんどのUNIX/Linuxユーティリティは何かが起こったときに名前を書くと思うので、それは良いことのようですが、それを行う方法と行わない方法についてのガイドラインや不文律はありますか？

たとえば、バイナリを/usr/bin/の下にインストールするのではなく、/usr/local/bin/などの下にインストールすることをお勧めします。 stderrへの出力について同様のルールはありますか？名前の後にコロンを付ける必要がありますか？または単に「警告！」と「エラー！」言葉？何も見つかりませんでしたが、誰かが私にそれについて読む場所を教えてくれるかもしれません。

この質問はプログラミングの実践について少しですが、UNIX/Linuxの伝統に関するものであり、一般的なプログラミングではないため、 stackoverflow よりもここの方が適切だと思いました。

stderrunix-philosophy
13
gsarret

Cプログラムmainに渡された0th引数を保存し、それをperrorのパラメーターとして使用するのが一般的な方法です—単純なプログラムの場合：

_#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    char *foo = malloc(9999999999L);
    if (foo == 0)
        perror(argv[0]);
    return 0;
}
_

そのプログラムを「foo」と呼び、それを実行すると、ポイントがわかります。

_> ./foo
./foo: Cannot allocate memory
_

複雑なプログラムはテキストに追加される場合があります（またはパスなしでファイル名のみを使用します）が、プログラム名を保持することで、不正なプログラムがどこから来たのかを見つけることができます。

エラーメッセージに対して広く受け入れられているスキームはありませんが、広く使用されているプログラム（gccなど）の中には、「エラー」や「警告」などのメッセージカテゴリを追加するものがあります。これが私のビルドログの1つからの例です：

_compiling fld_def (obj_s)
../form/fld_def.c: In function '_nc_Copy_Argument':
../form/fld_def.c:164:14: warning: cast discards 'const' qualifier from pointer target type [-Wcast-qual]
        res = (TypeArgument *)argp;
              ^
_

この例では、gccはフィールドをコロンで区切り、ファイル名、行番号、列番号の後、実際のメッセージの前に「警告」カテゴリを追加します。しかし、いくつかのバリエーションがあり、プログラム（ vi-like-emacs など）が情報を解析するのが複雑になっています。

コンパイラの場合、メッセージでcategoryを使用すると、致命的なエラー（ではない場合があります）をすぐに検出できます。致命的）および警告。プログラムがエラーで終了した場合、実際に警告であるものとエラーであるものがあると言ってもあまり意味がありません。ただし、動作が異なる場合（または動作が多かれ少なかれ継続する場合）、カテゴリは発生した問題の診断に役立ちます。

16
Thomas Dickey

他の多くのプログラムが呼び出されるスクリプトの一部としてプログラムが呼び出され、その名前が出力されない場合、ユーザーはエラーの原因を特定するのが困難になります。

（エラーがデバッグを必要とする可能性のある予期しない内部状態である場合は、プログラム名だけでなく、ソースファイルと行番号、場合によってはバックトレースなど、さらに詳しい情報が必要です。）

8
Kaz