Les rapports d'avancement / informations de journalisation appartiennent-ils à stderr ou stdout?

Existe-t-il une directive officielle POSIX, GNU ou autre indiquant l'endroit où les rapports d'avancement et les informations de journalisation (des choses telles que "Doing foo; foo done") doivent être imprimés? Personnellement, j'ai tendance à les écrire sur stderr pour pouvoir rediriger stdout et obtenir uniquement la sortie réelle du programme. On m'a récemment dit que ce n'était pas une bonne pratique puisque les rapports d'avancement ne sont pas réellement des erreurs et que seuls les messages d'erreur doivent être imprimés sur stderr.

Les deux positions ont du sens, et vous pouvez bien sûr choisir l’une ou l’autre en fonction des détails de ce que vous faites, mais je voudrais savoir s’il existe une norme communément acceptée à cet égard. Je n'ai pas pu trouver de règles spécifiques dans POSIX, dans les normes de codage GNU, ni dans aucune autre liste de bonnes pratiques largement acceptée.

Nous avons quelques questions similaires, mais elles ne traitent pas de cette question précise:

• Quand utiliser la redirection vers stderr dans les scripts de shell : La réponse acceptée suggère ce que j'ai tendance à faire: conservez la sortie finale du programme sur stdout et sur toute autre chose pour stderr. Cependant, ceci est simplement présenté comme une opinion d'utilisateur, bien que soutenue par des arguments.

• Le message d'utilisation doit-il aller à stderr ou stdout? : Ceci est spécifique aux messages d’aide mais cite la norme de codage GNU. C'est le genre de chose que je recherche, mais pas uniquement pour aider les messages.

Alors, y a-t-il des règles officielles sur l'endroit où les rapports d'avancement et autres messages informatifs (qui ne font pas partie du résultat réel du programme) doivent être imprimés?

Posix définit les flux standards ainsi :

Au démarrage du programme, trois flux doivent être prédéfinis et ne doivent pas être ouverts explicitement: entrée standard (pour lire une entrée conventionnelle), sortie standard (pour écrire une sortie conventionnelle) et erreur standard (pour écrire une sortie de diagnostic). Lorsqu'il est ouvert, le flux d'erreur standard n'est pas entièrement mis en mémoire tampon; les flux d'entrée et de sortie standard sont entièrement mis en mémoire tampon si et seulement s'il est possible de déterminer que le flux ne fait pas référence à un périphérique interactif.

La bibliothèque GNU C décrit les flux standard de la même manière:

Variable: FILE * stdout
Le flux de sortie standard, utilisé pour la sortie normale du programme.

Variable: FILE * stderr
Le flux d'erreur standard, utilisé pour les messages d'erreur et les diagnostics émis par le programme.

Ainsi, les définitions standard donnent peu d'indications sur l'utilisation des flux au-delà des «sorties conventionnelles / normales» et «sorties diagnostiques / d'erreurs». En pratique, il est courant de rediriger l'un ou l'autre de ces flux vers des fichiers et des pipelines, où les indicateurs de progression poseront problème. . Certains systèmes surveillent même lesstderr résultats et le considèrent comme un signe de problèmes. Les informations de progression purement auxiliaires sont donc problématiques sur l'un ou l'autre flux.

Au lieu d'envoyer des indicateurs de progression de manière inconditionnelle à l'un ou l' autre des flux standard, il est important de reconnaître que le résultat des progrès n'est approprié que pour les flux interactifs . Dans cet esprit, je vous recommande d'écrire les compteurs de progression uniquement après avoir vérifié si le flux est interactif (par exemple, avec isatty()) ou s'il est explicitement activé par une option de ligne de commande. Cela est particulièrement important pour les compteurs de progression qui s'appuient sur le comportement de mise à jour du terminal, comme les barres%-complètes.

Pour certains messages de progression très simples («Démarrage de X» ... «Terminé avec X»), il est plus raisonnable d'inclure la sortie même pour les flux non interactifs. Dans ce cas, réfléchissez à la manière dont les utilisateurs pourraient interagir avec les flux, tels que la recherche avec grepou la pagination avec lessou la surveillance avec tail -f. S'il est logique de voir les messages de progrès dans ces contextes, ils seront beaucoup plus faciles à consommer stdout.

POSIX définit l'erreur standard comme

pour écrire une sortie de diagnostic

Cela ne limite pas son utilisation aux seuls messages d'erreur. Je considérerais les informations de progression comme une sortie de diagnostic, ce qui en fait une erreur standard.

Posix est un peu plus concret sur « des informations de diagnostic » dans Shell et utilitaires , 1.4: Utilitaire Description Par défaut (Souligné par ):

STDERR

La section STDERR décrit la sortie d'erreur standard de l'utilitaire. Seuls les messages envoyés à dessein par l'utilitaire sont décrits. L'utilisation d'un terminal pour l'erreur standard peut entraîner l'arrêt de l'un des utilitaires standard qui écrivent une sortie d'erreur standard lorsqu'il est utilisé en arrière-plan. Pour cette raison, les applications ne doivent pas utiliser les fonctionnalités interactives dans les scripts pour être placées en arrière-plan.

Le format des messages de diagnostic pour la plupart des utilitaires n'est pas spécifié, mais les conventions linguistiques et culturelles des messages de diagnostic et d'information dont le format n'est pas spécifié par ce volume de POSIX.1-2008 devraient être affectées par les paramètres LC_MESSAGES et [XSI] [Option Start ] NLSPATH. [Option Fin]

La sortie d'erreur standard spécifiée des utilitaires standard ne doit pas dépendre de l'existence ou de la valeur des variables d'environnement définies dans ce volume de POSIX.1-2008, sauf dans les cas prévus par ce volume de POSIX.1-2008.

Comportement par défaut : Lorsque cette section est listée comme "L’erreur standard ne doit être utilisée que pour les messages de diagnostic.", Cela signifie que, sauf indication contraire, les messages de diagnostic ne doivent être envoyés à l’erreur standard que lorsque l’état de sortie indique une erreur. s'est produite et que l'utilitaire est utilisé comme décrit dans ce volume de POSIX.1-2008.

Lorsque cette section est répertoriée comme "Non utilisé.", Cela signifie que l'erreur standard ne doit pas être utilisée lorsque l'utilitaire est utilisé comme décrit dans ce volume de POSIX.1-2008.

IANASL, mais j’interprète cela comme signifiant que stderr n’aura de sortie que si l’utilitaire renvoie un code de sortie d’erreur. Etant donné que cela ne devrait pas être le cours normal des événements pour une exécution réussie, aucune information de progression ne doit être imprimée par un utilitaire POSIX sauf en cas d'erreur (sauf indication contraire, bien sûr, etc.).

En vertu du principe d'exclusion, il ne peut aller que jusqu'à stderr. Oui, je sais que vous avez demandé une spécification officielle, que je ne peux pas vous présenter au-delà du lien vers la spécification POSIX, donnée par Stephen Kitt, qui stipule que stderr est utilisé à des fins de diagnostic.

Le point le plus important est que stdin et stdout ont une fonction qui interdit l'impression de rapports de progression sur stdout - ils forment bien sûr la séquence de canaux qui, dans les commandes de shell Unix, n'est pas qu'un simple effet secondaire, mais constitue le cœur même de la puissante approche de pipeline. .

Alors. Rien sauf la vraie "charge utile" de votre programme n'appartient à stdout. Si votre programme n'a pas de sortie, rien ne devrait aller à stdout. Cela laisse stderr pour tout le reste , y compris les rapports d'avancement.

Certes, cela laisse un trou - il serait probablement bien d’avoir un "stdfluff" ou quelque chose du genre qui n’a pour but ni la sortie ni les erreurs, mais les rapports de progression, le débogage, etc. En fait, rien ne vous empêche de le faire, c’est-à-dire que vous pouvez imprimer votre progression dans le descripteur de fichier 3. Exemple:

$ perl -e 'open($fd, ">", "/dev/fd/3"); print $fd "hello\n"'

Cela ne produit aucune sortie. (*)

$ perl -e 'open($fd, ">", "/dev/fd/3"); print $fd "hello\n"'  3>&1
hello

Ceci est imprimé sur fd-3, qui est redirigé sur stdout.

(*) Le premier exemple ne produit aucune sortie mais reste un peu tiré par les cheveux; les openéchoue et $!contiendrait no such file or directory; Prenez ceci comme exemple, il ne faut bien sûr pas en faire un usage sérieux. Dans un programme réel, si vous souhaitez emprunter cette voie, vous pouvez vérifier si vous pouvez l' /dev/fd/3utiliser ou non, et prendre cela comme un indice permettant d'activer ou non vos rapports d'avancement. vous devriez le faire assez tôt pour ne pas vous tromper de openfichiers personnels et autres ...

Le message d'utilisation doit aller à stdout si l'utilisateur l'a invoqué avec --helpet à stderr s'il s'est trompé. L'imprimer sur stderr inconditionnellement est odieux, car cela rend plus difficile sa visualisation avec un pager / grep / etc.

Aussi, puis-je suggérer une troisième voie: ouvrir / dev / tty pour les rapports d’avancement / tourneurs / etc.