Gibt es eine offizielle POSIX-, GNU- oder andere Richtlinie darüber, wo Fortschrittsberichte und Protokollinformationen (Dinge wie „Doing foo; foo done“) gedruckt werden sollten? Persönlich neige ich dazu, sie in 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 auf stderr ausgegeben werden sollten.
Beide Positionen sind sinnvoll, und natürlich können Sie je nach den Details Ihrer Tätigkeit die eine oder andere wählen, aber ich würde gerne wissen, ob es dafür einen allgemein anerkannten Standard gibt. Ich konnte keine spezifischen Regeln in POSIX, den GNU-Codierungsstandards oder anderen so weithin akzeptierten Listen von Best Practices finden.
Wir haben ein paar ähnliche Fragen, aber sie behandeln nicht genau dieses Problem:
-
Wann die Umleitung zu stderr in Shell-Skripten verwendet werden sollte:Die akzeptierte Antwort legt nahe, was ich zu tun neige, die endgültige Ausgabe des Programms auf stdout und alles andere auf stderr zu halten. Dies wird jedoch nur als Meinung eines Benutzers dargestellt, wenn auch durch Argumente gestützt.
-
Soll die Verwendungsnachricht an stderr oder stdout gehen?:Dies ist spezifisch für Hilfenachrichten, zitiert aber den GNU-Codierungsstandard. So etwas suche ich, aber nicht nur auf Hilfenachrichten beschränkt.
Gibt es also offizielle Regeln dafür, wo Fortschrittsberichte und andere informative Nachrichten (die nicht Teil der eigentlichen Ausgabe des Programms sind) gedruckt werden sollten?
Akzeptierte Antwort:
Posix definiert die Standard-Streams folgendermaßen:
Beim Programmstart sollen drei Streams vordefiniert sein und müssen nicht explizit geöffnet werden:Standardeingabe (zum Lesen konventioneller Eingaben), Standardausgabe (zum Schreiben einer konventionellen Ausgabe) und Standardfehler (zum Schreiben der Diagnoseausgabe). Beim Öffnen wird der Standardfehlerstrom nicht vollständig gepuffert; die Standardeingabe- und Standardausgabestreams werden vollständig gepuffert, wenn und nur wenn bestimmt werden kann, dass der Stream nicht auf ein interaktives Gerät verweist.
Die GNU C Library beschreibt die Standard-Streams ähnlich:
Variable:DATEI * stdout
Der Standardausgabestrom, der für die normale Ausgabe des Programms verwendet wird.
Variable:DATEI * stderr
Der Standardfehlerstrom, der für vom Programm ausgegebene Fehlermeldungen und Diagnosen verwendet wird.
Daher enthalten Standarddefinitionen wenig Anleitung für die Stream-Nutzung, die über „herkömmliche/normale Ausgabe“ und „Diagnose-/Fehlerausgabe“ hinausgeht. In der Praxis ist es üblich, einen oder beide dieser Streams an Dateien und Pipelines umzuleiten, wo Fortschrittsanzeigen ein Problem darstellen. Einige Systeme überwachen sogar stderr für die Ausgabe und betrachten Sie dies als Zeichen von Problemen. Reine Hilfsfortschrittsinformationen sind daher in beiden Streams problematisch.
Anstatt Fortschrittsanzeigen bedingungslos an entweder zu senden Standard-Stream ist es wichtig zu erkennen, dass die Fortschrittsausgabe nur für interaktive geeignet ist Ströme. Vor diesem Hintergrund empfehle ich, Fortschrittszähler erst zu schreiben, nachdem geprüft wurde, ob der Stream interaktiv ist (z. B. mit isatty()). ) oder bei expliziter Aktivierung durch eine Befehlszeilenoption. Das ist besonders wichtig für Fortschrittsanzeigen, die auf dem Aktualisierungsverhalten des Terminals beruhen, um sinnvoll zu sein, wie z. B. %-Complete-Balken.
Für bestimmte sehr einfache Fortschrittsmeldungen („Starting X“ … „Fertig mit X“) ist es sinnvoller, die Ausgabe auch für nicht-interaktive Streams einzuschließen. Überlegen Sie in diesem Fall, wie Benutzer mit den Streams interagieren könnten, wie z. B. die Suche mit grep oder Paging mit less oder Überwachung mit tail -f . Wenn es sinnvoll ist, die Fortschrittsmeldungen in diesen Kontexten zu sehen, sind sie viel einfacher von stdout aus zu konsumieren .