Dois-je afficher le nom du programme lorsqu'un avertissement ou une erreur se produit?

Si j'écris un script ou un programme, dois-je sortir vers stderr son nom avec un message d'avertissement ou d'erreur? Par exemple:

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

ou:

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

Je comprends que généralement c'est juste une question de goût (surtout si vous écrivez vous-même vos propres trucs), mais je me demande s'il y a quelque chose de conventionnel à cela? Je crois que la plupart des utilitaires UNIX / Linux écrivent leurs noms quand quelque chose se produit, donc cela semble être une bonne chose, mais y a-t-il des directives ou des règles tacites sur la façon de le faire et de ne pas le faire?

Par exemple, il n'est pas conseillé d'installer des binaires sous /usr/bin/, plutôt sous /usr/local/bin/ou autre chose. Existe-t-il des règles similaires sur la sortie vers stderr? Dois-je écrire le nom suivi de deux points? Ou tout simplement "Attention!" et "Erreur!" mots? Je n'ai rien trouvé mais peut-être que quelqu'un pourrait m'indiquer où lire à ce sujet.

Cette question concerne un peu les pratiques de programmation, mais j'ai pensé qu'elle était plus appropriée ici que sur stackoverflow , car elle concerne les traditions UNIX / Linux et non la programmation en général.

Il est courant de sauvegarder le 0ème argument passé à un programme C mainet de l'utiliser comme paramètre pour perror- pour les programmes simples:

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

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

appeler ce programme "foo", et son exécution illustre le point:

> ./foo
./foo: Cannot allocate memory

Les programmes compliqués peuvent s'ajouter au texte (ou utiliser uniquement le nom de fichier sans le chemin d'accès), mais conserver le nom du programme vous permet de trouver d'où provient un programme qui se comporte mal.

Il n'y a pas de schéma universellement accepté pour les messages d'erreur, mais certains programmes largement utilisés (tels que gcc) ajoutent une catégorie de message telle que "Erreur" ou "Avertissement". Voici un exemple de l'un de mes journaux de build:

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

Dans cet exemple, gcc sépare les champs par des deux-points et ajoute une catégorie "avertissement" après le nom de fichier, le numéro de ligne, le numéro de colonne - et avant le message réel. Mais il existe plusieurs variantes, ce qui complique l' analyse des informations par des programmes (tels que vi-like-emacs ).

Pour les compilateurs, l'utilisation d'une catégorie dans le message facilite la détection des erreurs fatales (qui peuvent ne pas être immédiatement fatales ) et des avertissements. Si votre programme se termine sur une erreur, cela n'ajoute pas grand chose à dire que certains sont vraiment des avertissements et d'autres sont des erreurs. Mais lorsqu'elle se comporte différemment (ou continue de fonctionner plus ou moins), la catégorie permet de diagnostiquer le problème rencontré.

Si un programme est invoqué dans le cadre d'un script dans lequel de nombreux autres programmes sont invoqués et s'il n'imprime pas son nom, les utilisateurs auront du mal (euh) à comprendre d'où vient l'erreur.

(Si l'erreur est une condition interne inattendue qui peut nécessiter un débogage, vous voulez encore plus d'informations: pas seulement le nom du programme, mais un fichier source et un numéro de ligne et éventuellement une trace.)