I rapporti sui progressi / le informazioni di registrazione appartengono a stderr o stdout?

Esiste un POSIX ufficiale, GNU o altre linee guida su dove dovrebbero essere stampate le relazioni sui progressi e le informazioni di registrazione (cose come "Fare foo; foo done")? Personalmente, tendo a scriverli su stderr in modo da poter reindirizzare stdout e ottenere solo l'output effettivo del programma. Recentemente mi è stato detto che questa non è una buona pratica poiché i rapporti sui progressi non sono in realtà errori e solo i messaggi di errore dovrebbero essere stampati su stderr.

Entrambe le posizioni hanno un senso, e ovviamente puoi scegliere l'una o l'altra a seconda dei dettagli di ciò che stai facendo, ma vorrei sapere se esiste uno standard comunemente accettato per questo. Non sono stato in grado di trovare regole specifiche in POSIX, negli standard di codifica GNU o in qualsiasi altro elenco di best practice ampiamente accettato.

Abbiamo alcune domande simili, ma non affrontano questo problema esatto:

• Quando utilizzare il reindirizzamento a stderr negli script di shell : la risposta accettata suggerisce ciò che tendo a fare, mantenere l'output finale del programma su stdout e qualsiasi altra cosa su stderr. Tuttavia, questo è appena presentato come opinione dell'utente, sebbene supportato da argomenti.

• Il messaggio di utilizzo dovrebbe andare su stderr o stdout? : Questo è specifico per aiutare i messaggi ma cita lo standard di codifica GNU. Questo è il tipo di cosa che sto cercando, non solo per aiutare i messaggi.

Quindi, ci sono delle regole ufficiali su dove dovrebbero essere stampati rapporti sullo stato di avanzamento e altri messaggi informativi (che non fanno parte dell'output effettivo del programma)?

Posix definisce quindi i flussi standard :

All'avvio del programma, tre flussi devono essere predefiniti e non devono essere aperti in modo esplicito: input standard (per leggere input convenzionali), output standard (per scrivere output convenzionali) ed errore standard (per scrivere output diagnostici). Se aperto, il flusso di errori standard non è completamente bufferizzato; i flussi di input standard e output standard sono completamente bufferizzati se e solo se il flusso può essere determinato in modo da non fare riferimento a un dispositivo interattivo.

La libreria GNU C descrive i flussi standard in modo simile:

Variabile: FILE * stdout
Il flusso di output standard, utilizzato per l'output normale dal programma.

Variabile: FILE * stderr
Il flusso di errore standard, utilizzato per i messaggi di errore e la diagnostica emessi dal programma.

Pertanto, le definizioni standard hanno poche indicazioni per l'utilizzo del flusso oltre "output convenzionale / normale" e "output diagnostico / di errore". In pratica, è comune reindirizzare uno o entrambi questi flussi su file e pipeline, in cui gli indicatori di progresso saranno un problema . Alcuni sistemi monitorano persino l' stderroutput e lo considerano un segnale di problemi. Le informazioni sull'avanzamento puramente ausiliario sono quindi problematiche su entrambi i flussi.

Invece di inviare gli indicatori di progresso incondizionatamente a uno dei flussi standard, è importante riconoscere che l'output dei progressi è appropriato solo per i flussi interattivi . Con questo in mente, raccomando di scrivere contatori di avanzamento solo dopo aver verificato se il flusso è interattivo (ad es. Con isatty()) o se esplicitamente abilitato da un'opzione della riga di comando. Ciò è particolarmente importante per i misuratori di progresso che si basano sul comportamento di aggiornamento dei terminali per avere un senso, come le barre complete di%.

Per alcuni messaggi di avanzamento molto semplici ("Avvio di X" ... "Fine con X") è più ragionevole includere l'output anche per i flussi non interattivi. In tal caso, considera in che modo gli utenti potrebbero interagire con gli stream, come cercare grepo effettuare il paging lesso il monitoraggio con tail -f. Se ha senso vedere i messaggi di avanzamento in quei contesti, saranno molto più facili da consumare stdout.

POSIX definisce l'errore standard come

per scrivere output diagnostico

Ciò non limita il suo utilizzo solo ai messaggi di errore. Considererei le informazioni sui progressi come output diagnostici, quindi appartengono a errori standard.

POSIX è leggermente più concreto riguardo alle "informazioni diagnostiche" in Shell e Utilità , 1.4: Default Descrizione Utilità (enfasi):

STDERR

La sezione STDERR descrive l'output di errore standard dell'utilità. Vengono descritti solo i messaggi inviati di proposito dall'utilità. L'uso di un terminale per errore standard può causare l'interruzione di qualsiasi utilità standard che scrive l'output di errore standard quando utilizzato in background. Per questo motivo, le applicazioni non devono utilizzare funzionalità interattive negli script per essere posizionate in background.

Il formato dei messaggi diagnostici per la maggior parte delle utility non è specificato, ma le convenzioni linguistiche e culturali dei messaggi diagnostici e informativi il cui formato non è specificato da questo volume di POSIX.1-2008 dovrebbero essere influenzate dall'impostazione di LC_MESSAGES e [XSI] [Opzione Avvio ] NLSPATH. [Fine opzione]

L'output di errore standard specificato delle utility standard non dipende dall'esistenza o dal valore delle variabili di ambiente definite in questo volume di POSIX.1-2008, ad eccezione di quanto previsto da questo volume di POSIX.1-2008.

Comportamento predefinito : quando questa sezione è elencata come "L'errore standard deve essere utilizzato solo per i messaggi diagnostici", significa che, se non diversamente indicato, i messaggi diagnostici devono essere inviati all'errore standard solo quando lo stato di uscita indica che un errore si è verificato e l'utilità viene utilizzata come descritto da questo volume di POSIX.1-2008.

Quando questa sezione è elencata come "Non utilizzato", significa che l'errore standard non deve essere utilizzato quando si utilizza l'utilità come descritto in questo volume di POSIX.1-2008.

IANASL, ma interpreto ciò per indicare che stderr avrà un output solo se l'utility restituirà un codice di uscita dell'errore. Dal momento che questo non dovrebbe essere il normale corso degli eventi per un'esecuzione corretta, nessuna informazione sull'avanzamento dovrebbe essere stampata da un'utilità POSIX a meno che non si verifichi un errore (a meno che, ovviamente, diversamente specificato, ecc.).

Secondo il principio di esclusione, può solo andare a stderr. Sì, so che hai chiesto informazioni su una specifica ufficiale, che non posso presentarti oltre il collegamento alla specifica POSIX, data da Stephen Kitt, che afferma che stderr è a fini diagnostici.

Il punto più importante è che stdin e stdout hanno una funzione che non consente di stampare report di avanzamento su stdout - ovviamente formano la sequenza di pipe che nei comandi della shell Unix non è solo un effetto collaterale, ma il nucleo stesso del potente approccio di pipelining .

Così. Nulla, tranne il vero "payload" del tuo programma, appartiene a stdout. Se il tuo programma non ha output, allora nulla dovrebbe andare su stdout. Questo lascia stderr per tutto il resto , compresi i rapporti sui progressi.

Certo, questo lascia un buco - sarebbe probabilmente bello avere uno "stdfluff" o qualcosa del genere che non è né per output né per errori, ma per i rapporti sui progressi, il debugging e altro. In realtà, nulla ti impedisce di farlo, ad esempio, potresti stampare i tuoi progressi sul descrittore di file 3. Esempio:

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

Questo non produce output. (*)

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

Questo stampa su fd-3, che viene reindirizzato su stdout.

(*) Il primo esempio non produce output ma è ancora un po 'inverosimile; i openfallimenti e $!conterrebbero no such file or directory; prendi questo come esempio, ovviamente non è un modo di essere usato in questo modo sul serio. In un programma reale, se si desidera seguire questa strada, è possibile verificare se /dev/fd/3è utilizzabile e prendere questo come suggerimento per l'attivazione dei rapporti sui progressi compiuti; dovresti farlo abbastanza presto in modo da non confonderti con i tuoi openfile reali e simili ...

Il messaggio di utilizzo dovrebbe andare su stdout se l'utente lo ha invocato --helpe su stderr se ha commesso un errore. Stamparlo su stderr incondizionatamente è odioso perché rende più difficile visualizzarlo con un cercapersone / grep / etc.

Inoltre, posso suggerire una terza via: open / dev / tty per i report sui progressi / spinner / ecc.