Czy powinienem wypisywać nazwę programu, gdy pojawi się ostrzeżenie lub błąd?

Jeśli piszę skrypt lub program, czy powinienem wypisywać na stderr jego nazwę wraz z ostrzeżeniem lub komunikatem o błędzie? Na przykład:

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

lub:

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

Rozumiem, że generalnie jest to tylko kwestia gustu (zwłaszcza jeśli piszesz własne rzeczy dla siebie), ale zastanawiam się, czy jest w tym coś konwencjonalnego? Wierzę, że większość narzędzi UNIX / Linux zapisuje swoje nazwy, gdy coś się dzieje, więc wydaje się to dobrą rzeczą, ale czy istnieją jakieś wytyczne lub niewypowiedziane zasady, jak to zrobić, a jak nie?

Na przykład, nie zaleca się instalowania plików binarnych pod /usr/bin/, raczej pod /usr/local/bin/lub coś innego. Czy istnieją podobne zasady dotyczące wyjścia do stderr? Czy powinienem napisać imię i dwukropek? Lub po prostu „Ostrzeżenie!” i „Błąd!” słowa? Nie mogłem nic znaleźć, ale może ktoś mógłby wskazać mi, gdzie mam o tym przeczytać.

To pytanie dotyczy trochę praktyk programistycznych, ale pomyślałem, że jest bardziej odpowiednie tutaj niż na przepełnieniu stosu , ponieważ dotyczy tradycji UNIX / Linux, a nie programowania w ogóle.

Powszechną praktyką jest zapisywanie 0. argumentu przekazanego do programu w C maini użycie go jako parametru dla perror- dla prostych programów:

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

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

nazwij ten program „foo”, a jego uruchomienie ilustruje tę kwestię:

> ./foo
./foo: Cannot allocate memory

Skomplikowane programy mogą dodawać do tekstu (lub używać tylko nazwy pliku bez ścieżki), ale zachowanie nazwy programu pozwala dowiedzieć się, skąd pochodzi niewłaściwie działający program.

Nie ma powszechnie akceptowanego schematu komunikatów o błędach, ale niektóre powszechnie używane programy (takie jak gcc) dodają kategorię komunikatów, taką jak „Błąd” lub „Ostrzeżenie”. Oto przykład z jednego z moich dzienników kompilacji:

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

W tym przykładzie gcc oddziela pola dwukropkami i dodaje kategorię „ostrzeżenie” po nazwie pliku, numerze wiersza, numerze kolumny - i przed rzeczywistym komunikatem. Istnieje jednak kilka odmian, co utrudnia programom (takim jak emac-vi ) analizowanie informacji.

W przypadku kompilatorów użycie kategorii w komunikacie ułatwia wykrycie błędów krytycznych (które mogą nie być natychmiastowe ) i ostrzeżeń. Jeśli twój program kończy działanie z błędem, niewiele mówi, że niektóre są naprawdę ostrzeżeniami, a niektóre błędami. Ale gdy zachowuje się inaczej (lub działa mniej więcej), kategoria pomaga zdiagnozować napotkany problem.

Jeśli program jest wywoływany jako część skryptu, w którym wywoływane jest wiele innych programów, a jeśli nie wypisuje swojej nazwy, użytkownicy będą mieli trudności z ustaleniem, skąd pochodzi błąd.

(Jeśli błąd jest nieoczekiwanym warunkiem wewnętrznym, który może wymagać debugowania, potrzebujesz jeszcze więcej informacji: nie tylko nazwy programu, ale pliku źródłowego i numeru wiersza i ewentualnie śledzenia wstecznego).