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

スクリプトまたはプログラムを作成している場合、警告またはエラーメッセージとともにその名前を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よりもこちらの方が適切だと思いました。

Cプログラムに渡される0番目の引数を保存し、mainそれをパラメーターとして使用するのが一般的な方法です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など）が情報を解析するのを複雑にします。

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

他の多くのプログラムが呼び出されるスクリプトの一部としてプログラムが呼び出され、その名前が出力されない場合、ユーザーはエラーの原因を突き止めるのが難しいでしょう。

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