Quand utiliser le flux d'erreur standard dans une application en ligne de commande?

Existe-t-il une indication quant à l'utilisation de l'erreur lors de l'écriture d'une application en ligne de commande? À ma grande surprise, je n'ai rien trouvé sur Google.

En particulier, la question qui m'inquiète en ce moment est de savoir s'il faut utiliser stdoutou stderrquand l'utilisateur a appelé le programme avec des arguments illégaux. Cependant, une réponse plus complète est très appréciée car ce ne sera sûrement pas le seul cas dans lequel une règle claire est nécessaire pour écrire un programme qui se comporte de la manière attendue par l'utilisateur.

Oui, affichez un message stderrlorsque les mauvais arguments sont utilisés. Et si cela entraîne également la fermeture de l'application, quittez avec un état de sortie différent de zéro.

Vous devez utiliser le flux d'erreurs standard pour les messages de diagnostic ou pour l'interaction avec l'utilisateur. Les messages de diagnostic incluent des messages d'erreur, des avertissements et d'autres messages qui ne font pas partie de la sortie de l'utilitaire lorsqu'il fonctionne correctement («correctement» signifiant qu'il ne se passe rien d'exceptionnel, comme les fichiers non trouvés ou quoi que ce soit).

De nombreux shells (tous?) Affichent des invites, les types d'utilisateurs, les menus, etc. stderrpour que la redirection stdoutne vous empêche pas d'interagir avec le shell de manière significative.

Voici un article de blog sur ce sujet:

Ceci est une citation de Doug McIllroy, inventeur des tuyaux Unix, expliquant comment stderrest né. 'v6' fait référence à une version d'une version spécifique du système d'exploitation Unix original qui a été publié en 1975.

Tous les programmes ont placé des diagnostics sur la sortie standard. Cela avait toujours causé des problèmes lorsque la sortie était redirigée vers un fichier, mais était devenu intolérable lorsque la sortie était envoyée à un processus sans méfiance. Néanmoins, ne voulant pas violer la simplicité du modèle d'entrée-standard-sortie-standard, les gens ont toléré cet état de fait via la v6. Peu de temps après, Dennis Ritchie a coupé le nœud gordien en introduisant le fichier d'erreur standard. Ce n'était pas tout à fait suffisant. Avec les pipelines, les diagnostics peuvent provenir de plusieurs programmes exécutés simultanément. Les diagnostics devaient s'identifier.
- Doug McIllroy, "Un lecteur de recherche UNIX: extraits annotés du manuel du programmeur, 1971-1986"

"S'identifier" signifie simplement dire "Hé! C'est moi qui parle! Cela a mal tourné: [...]":

$ ls nothere
ls: nothere: No such file or directory

Faire ceci stderrest préférable, car il pourrait autrement être lu par ce qui était en train de lire stdout(mais nous ne le faisons pas de lstoute façon , n'est-ce pas ?).

À partir des spécifications POSIX pour les flux standard:

Au démarrage du programme, trois flux doivent être prédéfinis et n'ont pas besoin d'être ouverts explicitement: entrée standard (pour lire l'entrée conventionnelle), sortie standard (pour écrire la sortie conventionnelle) et erreur standard (pour écrire la sortie de diagnostic ).

En d'autres termes, les erreurs, les informations de débogage et tout ce qui relève de la catégorie de diagnostic sont inclus stderr.

Voir la question connexe pour plus d'informations: les rapports de progression / informations de journalisation appartiennent-ils à stderr ou stdout?