當出現警告或錯誤時，我應該輸出程序的名稱嗎？

如果我正在編寫腳本或程序，我應該將其名稱與警告或錯誤消息一起輸出到 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 的類似規則？我應該寫名字後跟冒號嗎？或者只是“警告！” 和“錯誤！” 字？我找不到任何東西，但也許有人可以指出我在哪裡閱讀它。

這個問題有點關於程式實踐，但我認為在這里而不是在stackoverflow上更合適，因為它是關於 UNIX/Linux 傳統而不是一般程式。

通常的做法是保存傳遞給 C 程序的第 0main個參數並將其用作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）添加了消息類別，例如“錯誤”或“警告”。這是我的一個建構日誌中的一個範例：

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）解析資訊變得複雜。

對於編譯器，在消息中使用類別可以輕鬆檢測致命錯誤（可能不會立即致命）和警告。如果您的程序因錯誤而退出，則說明有些是真正的警告和有些是錯誤並沒有什麼意義。但是當它表現不同（或或多或少地繼續工作）時，該類別有助於診斷遇到的問題。

引用自：https://unix.stackexchange.com/questions/307338