Quando utilizzare il reindirizzamento a stderr negli script di shell

15

So che programmi di utilità ben educati come grep generano messaggi "normali" su stdout e messaggi di errore su stderr.

$ grep '^foo' file1 file2
file1:foo
grep: file2: No such file or directory

Quando scrivo da solo gli script di shell, trovo spesso difficile decidere quale output e quali messaggi dovrei presentare su stderr o se dovrei preoccuparmi affatto.

Mi piacerebbe conoscere le buone pratiche: quando è necessario e ragionevole reindirizzare un messaggio a stderr e quando no?

"Dipende", certo, ma hai qualche idea che mi aiuterebbe a prendere queste decisioni?

Al fine di adattare questa domanda soggettiva al formato, vorrei incoraggiare le risposte che affrontano il "perché" e sono informate dall'esperienza e, se possibile, supportate da fatti.

— GltS
fonte

@rush lo spiega perfettamente. Di solito stampo rapporti sullo stato di avanzamento su stderr per lunghi script.

— terdon

12

Quando scrivo da solo gli script di shell, trovo spesso difficile decidere quale output e quali messaggi dovrei presentare su stderr o se dovrei preoccuparmi affatto.

Il silenzio è d'oro. Non produrre nulla se tutto va bene.

Mi piacerebbe conoscere le buone pratiche: quando è necessario e ragionevole reindirizzare un messaggio a stderr e quando no?

Il modo più semplice per separare stderr da stdout: immagina che tutto l'output degli script verrà reindirizzato a un altro comando tramite pipe. In tal caso, è necessario conservare tutte le notifiche in stderr, poiché tali informazioni impreviste in stdout potrebbero interrompere la sequenza di pipe.

Anche a volte in tubi come questo:

command1 | while read line ; do command2 ; done | command3

è necessario passare qualcosa command2all'output degli utenti. Il modo più semplice senza file temporanei è stderr.

— corsa
fonte

Grazie per l'idea "immaginare una pipa". A volte ho distribuito script che non fanno altro che "notificare" ( echoalcune variabili, mostrano cosa è stato fatto, mostrano progressi). Esito a mettere tutto su stderr poiché questi messaggi di log sono tutti gli script che verranno mai emessi. Non sono sicuro di come applicare l'idea di pipa in queste situazioni.

— inizia il

1

I programmi @glts vengono sempre modificati e migliorati. Mentre gli script che menzioni non generano alcun dato ora, potrebbero in seguito o potresti usarli come punti di partenza per altri script che lo fanno. Se segui la convenzione per cominciare, riceverai molte meno sorprese in seguito. OTOH, se vuoi solo salvare l'output in un file, devi reindirizzare stderr, quindi è un compromesso come tutto il resto.

— Joe,

+1 Un'altra parafrasi: assicurati che stdout sia sempre leggibile dalla macchina, o almeno contenga utili dati testuali in un formato coerente.

— Tripleee,

2

In genere scrivo tutto ciò che riguarda l'operazione dell'applicazione stderr, stdoutè riservato ai dati.

Immagina un'applicazione come cat. Quando lo si utilizza per leggere l'input e passarlo a un'altra applicazione (tramite una pipe), non si desidera che l'output sia disseminato di messaggi di stato.

Tutto ciò che potrebbe essere interessante per un'altra applicazione o un postprocessore per la mia applicazione lo farà stdout, tutto ciò che riguarda solo l'interno della mia applicazione stderr.

— Der Hochstapler
fonte

0

La mia preferenza personale è di inviare messaggi di errore, eccezioni stderre messaggi informativi a stdout. IMO, stderrè per qualsiasi eccezione e, quindi, la mia convenzione.

— unxnut
fonte