Gehören Fortschrittsberichte / Protokollinformationen zu stderr oder stdout?

Gibt es eine offizielle POSIX-, GNU- oder andere Richtlinie, in der Fortschrittsberichte und Protokollinformationen (z. B. "Doing foo; foo done") gedruckt werden sollten? Persönlich neige ich dazu, sie an stderr zu schreiben, damit ich stdout umleiten und nur die tatsächliche Ausgabe des Programms erhalten kann. Mir wurde kürzlich gesagt, dass dies keine gute Praxis ist, da Fortschrittsberichte eigentlich keine Fehler sind und nur Fehlermeldungen an stderr gedruckt werden sollten.

Beide Positionen sind sinnvoll, und natürlich können Sie die eine oder die andere auswählen, je nachdem, was Sie im Detail tun, aber ich würde gerne wissen, ob es dafür einen allgemein akzeptierten Standard gibt. Ich konnte in POSIX, den GNU-Codierungsstandards oder anderen allgemein akzeptierten Listen mit Best Practices keine spezifischen Regeln finden.

Wir haben ein paar ähnliche Fragen, die sich jedoch nicht genau mit diesem Thema befassen:

• Verwendung der Umleitung für stderr in Shell-Skripten : Die akzeptierte Antwort schlägt vor, was ich tendenziell tue, die endgültige Ausgabe des Programms auf stdout und alles andere auf stderr zu belassen. Dies wird jedoch nur als eine Meinung des Benutzers dargestellt, obwohl dies durch Argumente gestützt wird.

• Sollte die Verwendungsmeldung an stderr oder stdout gehen? : Dies ist spezifisch für Hilfemeldungen, zitiert jedoch den GNU-Codierungsstandard. Dies ist die Art von Dingen, die ich suche, nur nicht auf Hilfemeldungen beschränkt.

Gibt es also offizielle Regeln, wo Fortschrittsberichte und andere informative Nachrichten (die nicht Teil der tatsächlichen Ausgabe des Programms sind) gedruckt werden sollen?

Posix definiert die Standardströme somit :

Beim Programmstart müssen drei Datenströme vordefiniert und nicht explizit geöffnet werden: Standardeingabe (zum Lesen der konventionellen Eingabe), Standardausgabe (zum Schreiben der konventionellen Ausgabe) und Standardfehler (zum Schreiben der Diagnoseausgabe). Beim Öffnen ist der Standardfehlerstrom nicht vollständig gepuffert. Die Standardeingabe- und Standardausgabestreams werden nur dann vollständig gepuffert, wenn festgestellt werden kann, dass der Stream nicht auf ein interaktives Gerät verweist.

Die GNU C Library beschreibt die Standard-Streams ähnlich:

Variable: FILE * stdout
Der Standardausgabestream, der für die normale Ausgabe des Programms verwendet wird.

Variable: FILE * stderr
Der Standardfehlerstrom, der für vom Programm ausgegebene Fehlermeldungen und Diagnosen verwendet wird.

Standarddefinitionen enthalten daher nur wenige Richtlinien für die Stream-Verwendung, die über die Standard- / Normalausgabe und die Diagnose- / Fehlerausgabe hinausgehen. In der Praxis ist es üblich, einen oder beide dieser Streams auf Dateien und Pipelines umzuleiten, bei denen Fortschrittsanzeigen ein Problem darstellen . Einige Systeme überwachen sogar diestderr Ausgabe und sehen dies als Anzeichen für Probleme an. Lediglich zusätzliche Fortschrittsinformationen sind daher in beiden Streams problematisch.

Anstatt Fortschrittsanzeigen bedingungslos an einen der Standard-Streams zu senden , ist es wichtig zu erkennen, dass die Fortschrittsausgabe nur für interaktive Streams geeignet ist . Aus diesem Grund empfehle ich, Fortschrittszähler erst zu schreiben, nachdem Sie überprüft haben, ob der Stream interaktiv ist (z. B. mit isatty()) oder wenn er explizit über eine Befehlszeilenoption aktiviert wurde. Dies ist besonders wichtig für Fortschrittsanzeigen, bei denen das Aktualisierungsverhalten des Terminals sinnvoll ist, z. B.% -vollständige Balken.

Für bestimmte sehr einfache Fortschrittsmeldungen ("Starten von X" ... "Fertig mit X") ist es sinnvoller, die Ausgabe auch für nicht interaktive Streams einzuschließen. In diesem Fall sollten Sie überlegen, wie Benutzer mit den Streams interagieren können, z. B. mit suchen, mit greppagen lessoder mit überwachen tail -f. Wenn es sinnvoll ist, die Fortschrittsmeldungen in diesen Kontexten zu sehen, sind sie viel einfacher zu konsumieren stdout.

POSIX definiert Standardfehler als

zum Schreiben von Diagnoseausgaben

Dies beschränkt die Verwendung nicht nur auf Fehlermeldungen. Ich würde Fortschrittsinformationen als Diagnoseausgabe betrachten, so dass sie zu Standardfehlern gehören.

POSIX ist etwas konkreter in Bezug auf "Diagnoseinformationen" in Shell und Dienstprogrammen , 1.4: Standardwerte für Dienstprogrammbeschreibung (Schwerpunkt Mine):

STDERR

Der Abschnitt STDERR beschreibt die Standardfehlerausgabe des Dienstprogramms. Es werden nur die Nachrichten beschrieben, die vom Dienstprogramm absichtlich gesendet werden. Die Verwendung eines Terminals für Standardfehler kann dazu führen, dass alle Standarddienstprogramme, die Standardfehler ausgeben, bei Verwendung im Hintergrund angehalten werden. Aus diesem Grund sollten Anwendungen keine interaktiven Funktionen in Skripten verwenden, um sie in den Hintergrund zu stellen.

Das Format der Diagnosemeldungen für die meisten Dienstprogramme ist nicht festgelegt, aber die sprachlichen und kulturellen Konventionen von Diagnose- und Informationsmeldungen, deren Format in dieser Ausgabe von POSIX.1-2008 nicht festgelegt ist, sollten durch die Einstellung von LC_MESSAGES und [XSI] [Option Start] beeinflusst werden ] NLSPATH. [Optionsende]

Die angegebene Standardfehlerausgabe von Standarddienstprogrammen darf nicht von der Existenz oder dem Wert der Umgebungsvariablen abhängen, die in diesem Band von POSIX.1-2008 definiert sind, es sei denn, dies wird in diesem Band von POSIX.1-2008 bereitgestellt.

Standardverhalten : Wenn dieser Abschnitt als "Der Standardfehler darf nur für Diagnosemeldungen verwendet werden." Aufgeführt ist, bedeutet dies, dass die Diagnosemeldungen , sofern nicht anders angegeben, nur dann an den Standardfehler gesendet werden, wenn der Beendigungsstatus einen Fehler anzeigt aufgetreten ist und das Dienstprogramm wie in diesem Band von POSIX.1-2008 beschrieben verwendet wird.

Wenn dieser Abschnitt als "Nicht verwendet" aufgeführt ist, bedeutet dies, dass der Standardfehler nicht verwendet werden soll, wenn das Dienstprogramm wie in diesem Band von POSIX.1-2008 beschrieben verwendet wird.

IANASL, aber ich interpretiere das so, dass stderr nur ausgegeben wird, wenn das Dienstprogramm einen Fehler-Exit-Code zurückgibt. Da dies nicht der normale Ablauf für eine erfolgreiche Ausführung sein sollte, sollten von einem POSIX-Dienstprogramm keine Fortschrittsinformationen gedruckt werden, sofern kein Fehler auftritt (sofern natürlich nichts anderes angegeben ist usw.).

Nach dem Ausschlussprinzip kann es nur an stderr gehen. Ja, ich weiß, dass Sie nach einer offiziellen Spezifikation gefragt haben, die ich Ihnen nicht über den von Stephen Kitt angegebenen Link zur POSIX-Spezifikation hinaus vorstellen kann, der besagt, dass stderr für Diagnosezwecke bestimmt ist.

Der wichtigere Punkt ist, dass stdin und stdout eine Funktion haben, die das Drucken von Fortschrittsberichten für stdout nicht zulässt - sie bilden natürlich die Sequenz von Pipes, die in Unix-Shell-Befehlen nicht nur ein Nebeneffekt ist, sondern den Kern des leistungsstarken Pipelining-Ansatzes .

Damit. Auf stdout gehört nur die eigentliche "Nutzlast" Ihres Programms. Wenn Ihr Programm keine Ausgabe hat, sollte nichts auf stdout gehen. Dies lässt stderr für alles andere , einschließlich Fortschrittsberichte.

Zugegeben, dies hinterlässt eine Lücke - es wäre wahrscheinlich schön, ein "stdfluff" oder ähnliches zu haben, das weder für die Ausgabe noch für Fehler gedacht ist, sondern für Fortschrittsberichte, Debugging und ähnliches. Tatsächlich hindert Sie nichts daran, dies zu tun, dh Sie könnten Ihren Fortschritt in Dateideskriptor 3 ausgeben. Beispiel:

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

Dies erzeugt keine Ausgabe. (*)

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

Dies wird zu fd-3 gedruckt, das zu stdout umgeleitet wird.

(*) Das erste Beispiel erzeugt keine Ausgabe, ist aber noch etwas weit hergeholt. das openscheitert und $!würde enthalten no such file or directory; Nehmen Sie dies nur als Beispiel, es ist natürlich nicht ernst gemeint, so verwendet zu werden. Wenn Sie in einem tatsächlichen Programm diese Route einschlagen möchten, können Sie testen, ob /dev/fd/3es verwendbar ist, und dies als Hinweis darauf ansehen, ob Sie Ihre Fortschrittsberichte aktivieren möchten. Sie müssten das ziemlich früh tun, damit Sie nicht von Ihren eigenen opens für echte Dateien und so verwirrt werden ...

Die Benutzungsnachricht sollte auf stdout gehen, wenn der Benutzer sie mit aufgerufen hat, --helpund auf stderr, wenn er einen Fehler gemacht hat. Das bedingungslose Drucken auf stderr ist unangenehm, da es schwieriger ist, es mit einem Pager / grep / etc. Anzuzeigen.

Darf ich auch einen dritten Weg vorschlagen: open / dev / tty für Fortschrittsberichte / Spinner / etc.