Soll ich den Programmnamen ausgeben, wenn eine Warnung oder ein Fehler auftritt?

Wenn ich ein Skript oder ein Programm schreibe, soll ich den Namen zusammen mit einer Warnung oder einer Fehlermeldung an stderr ausgeben? Beispielsweise:

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

oder:

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

Ich verstehe, dass es im Allgemeinen nur eine Frage des Geschmacks ist (vor allem, wenn Sie Ihre eigenen Sachen für sich selbst schreiben), aber ich frage mich, ob daran etwas Konventionelles ist? Ich glaube, die meisten UNIX / Linux-Dienstprogramme schreiben ihre Namen, wenn etwas passiert. Es scheint also eine gute Sache zu sein, aber gibt es Richtlinien oder unausgesprochene Regeln, wie man das macht und wie man das nicht tut?

Zum Beispiel ist es nicht ratsam, Binärdateien unter /usr/bin/, sondern unter /usr/local/bin/oder etwas anderem zu installieren . Gibt es ähnliche Regeln für die Ausgabe an stderr? Soll ich den Namen gefolgt von einem Doppelpunkt schreiben? Oder nur "Warnung!" und "Fehler!" Wörter? Ich konnte nichts finden, aber vielleicht konnte mir jemand zeigen, wo ich darüber lesen kann.

Bei dieser Frage geht es ein wenig um Programmierpraktiken, aber ich fand, dass dies hier geeigneter ist als beim Stackoverflow , da es um UNIX / Linux-Traditionen und nicht um das Programmieren im Allgemeinen geht.

Es ist üblich, das an ein C-Programm übergebene Argument 0 zu speichern mainund dieses als Parameter für perror- für einfache Programme zu verwenden:

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

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

Nenne dieses Programm "foo" und starte es, um den Punkt zu veranschaulichen:

> ./foo
./foo: Cannot allocate memory

Komplizierte Programme können den Text ergänzen (oder nur den Dateinamen ohne Pfad verwenden). Wenn Sie jedoch den Programmnamen beibehalten, können Sie feststellen, woher ein sich schlecht verhaltendes Programm stammt.

Es gibt kein allgemein akzeptiertes Schema für Fehlermeldungen, aber einige weit verbreitete Programme (wie gcc) fügen eine Meldungskategorie wie "Fehler" oder "Warnung" hinzu. Hier ist ein Beispiel aus einem meiner Build-Logs:

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;
              ^

In diesem Beispiel trennt gcc Felder mit Doppelpunkten und fügt nach dem Dateinamen, der Zeilennummer, der Spaltennummer und vor der eigentlichen Nachricht eine "Warnung" der Kategorie ein. Es gibt jedoch verschiedene Variationen, die es für Programme (wie vi-like-emacs ) kompliziert machen , die Informationen zu analysieren.

Für Compiler macht es die Verwendung einer Kategorie in der Nachricht einfach, die schwerwiegenden Fehler (die möglicherweise nicht sofort schwerwiegend sind ) und Warnungen zu erkennen. Wenn Ihr Programm bei einem Fehler beendet wird, kann nicht viel hinzugefügt werden, um zu sagen, dass es sich bei einigen wirklich um Warnungen und bei anderen um Fehler handelt. Wenn es sich jedoch anders verhält (oder mehr oder weniger funktioniert), hilft die Kategorie bei der Diagnose des aufgetretenen Problems.

Wenn ein Programm als Teil eines Skripts aufgerufen wird, in dem viele andere Programme aufgerufen werden, und wenn der Name nicht gedruckt wird, können Benutzer nur schwer herausfinden, woher der Fehler stammt.

(Wenn es sich bei dem Fehler um einen unerwarteten internen Zustand handelt, der möglicherweise ein Debugging erfordert, möchten Sie noch mehr Informationen: nicht nur den Programmnamen, sondern auch eine Quelldatei und Zeilennummer und möglicherweise eine Rückverfolgung.)