Existe-t-il une directive officielle POSIX, GNU ou autre indiquant où les rapports d'avancement et les informations de journalisation (des choses comme "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 car les rapports d'avancement ne sont pas réellement des erreurs et seuls les messages d'erreur doivent être imprimés sur stderr.
Les deux positions ont du sens, et bien sûr vous pouvez choisir l'une ou l'autre en fonction des détails de ce que vous faites, mais j'aimerais savoir s'il existe une norme communément acceptée pour cela. Je n'ai trouvé aucune règle spécifique dans POSIX, les normes de codage GNU ou toute autre liste de bonnes pratiques largement acceptée.
Nous avons quelques questions similaires, mais elles ne traitent pas de ce problème précis :
-
Quand utiliser la redirection vers stderr dans les scripts shell :La réponse acceptée suggère ce que j'ai tendance à faire, garder la sortie finale du programme sur stdout et tout le reste sur stderr. Cependant, ceci est simplement présenté comme l'opinion d'un utilisateur, bien qu'étayé par des arguments.
-
Le message d'utilisation doit-il aller vers 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 seulement pour les messages d'aide.
Alors, existe-t-il des règles officielles sur l'endroit où les rapports d'avancement et autres messages informatifs (qui ne font pas partie de la sortie réelle du programme) doivent être imprimés ?
Réponse acceptée :
Posix définit ainsi les flux standards :
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 une sortie conventionnelle) et erreur standard (pour écrire la 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 si le flux peut être déterminé comme ne faisant pas référence à un appareil interactif.
La bibliothèque GNU C décrit les flux standard de la même manière :
Variable :FILE * sortie standard
Le flux de sortie standard, qui est utilisé pour la sortie normale du programme.Variable :FILE * stderr
Le flux d'erreur standard, qui est utilisé pour les messages d'erreur et les diagnostics émis par le programme.
Ainsi, les définitions standard ont peu de conseils pour l'utilisation du flux au-delà de la « sortie conventionnelle/normale » et de la « sortie de diagnostic/d'erreur ». 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 stderr pour la sortie et considérez cela comme un signe de problèmes. Les informations de progression purement auxiliaires sont donc problématiques sur l'un ou l'autre des flux.
Au lieu d'envoyer des indicateurs de progression inconditionnellement à l'un ou l'autre flux standard, il est important de reconnaître que la sortie de progression n'est appropriée que pour interactive ruisseaux. Dans cet esprit, je recommande d'écrire des compteurs de progression uniquement après avoir vérifié si le flux est interactif (par exemple, avec isatty() ) ou lorsqu'il est explicitement activé par une option de ligne de commande. C'est particulièrement important pour les compteurs de progression qui s'appuient sur le comportement de mise à jour du terminal pour avoir un sens, comme les barres %-complete.
Pour certains messages de progression très simples ("Starting X" … "Done with X"), il est plus raisonnable d'inclure la sortie même pour les flux non interactifs. Dans ce cas, réfléchissez à la façon dont les utilisateurs pourraient interagir avec les flux, comme la recherche avec grep ou la pagination avec less ou surveillance avec tail -f . S'il est logique de voir les messages de progression dans ces contextes, ils seront beaucoup plus faciles à consommer depuis stdout .