Quando utilizzare il flusso di errori standard nell'applicazione della riga di comando?

Esiste una linea guida quando utilizzare l'errore quando si scrive un'applicazione da riga di comando? Con mia sorpresa, non ho trovato nulla quando cercavo su Google.

In particolare, la domanda che mi interessa in questo momento è se utilizzare stdouto stderrquando l'utente ha chiamato il programma con argomenti illegali. Tuttavia, una risposta più completa è molto apprezzata perché questo sicuramente non sarà l'unico caso in cui è necessaria una chiara regola per scrivere un programma che si comporti nel modo previsto dall'utente.

— UTF-8
fonte

Va bene che quei messaggi di errore si confondano con l'output normale? Ad esempio, il programma è un filtro per i dati?

— thrig

Non è un filtro per i dati. Inoltre non è interattivo. L'utente lo chiama con argomenti (tra cui i percorsi dei file), il programma funziona, modifica quei file, stampa alcuni messaggi, idealmente non stampa alcun messaggio di errore e termina.

— UTF-8

Risposte:

Sì, visualizza un messaggio stderrquando vengono utilizzati argomenti errati. E se ciò causa anche la chiusura dell'applicazione, uscire con uno stato di uscita diverso da zero.

È necessario utilizzare il flusso di errori standard per i messaggi diagnostici o per l'interazione dell'utente. I messaggi diagnostici includono messaggi di errore, avvisi e altri messaggi che non fanno parte dell'output dell'utilità quando funziona correttamente ("correttamente" significa che non sta succedendo nulla di eccezionale, come i file non trovati, o qualunque cosa possa essere).

Molte shell (tutte?) Visualizzano prompt, cosa digita l'utente, menu ecc. In stderrmodo che il reindirizzamento stdoutnon ti impedisca di interagire con la shell in modo significativo.

Quanto segue proviene da un post di blog su questo argomento:

Questa è una citazione di Doug McIllroy, inventore delle pipe Unix, che spiega come è stderrnata. 'v6' si riferisce a una versione della versione specifica del sistema operativo Unix originale che è stata rilasciata nel 1975.

Tutti i programmi hanno posto la diagnostica sull'output standard. Ciò aveva sempre causato problemi quando l'output veniva reindirizzato in un file, ma diventava intollerabile quando l'output veniva inviato a un processo ignaro. Tuttavia, non volendo violare la semplicità del modello standard-input-standard-output, le persone hanno tollerato questo stato di cose attraverso la v6. Poco dopo Dennis Ritchie ha tagliato il nodo gordiano introducendo il file di errore standard. Non era abbastanza. Con le pipeline la diagnostica potrebbe venire da uno dei numerosi programmi eseguiti contemporaneamente. La diagnostica era necessaria per identificarsi.
- Doug McIllroy, "Un lettore UNIX di ricerca: estratti annotati dal Manuale del programmatore, 1971-1986"

"Identificarsi" significa semplicemente dire "Ehi! Sono io che parlo! È andato storto: [...]":

$ ls nothere
ls: nothere: No such file or directory

Fare questo su stderrè preferibile, dal momento che altrimenti potrebbe essere letto da qualunque cosa stesse leggendo stdout(ma non lo facciamo lscomunque , vero?).

— Kusalananda
fonte

Quindi quando chiedi all'utente qualcosa mentre l'applicazione è in esecuzione, dovresti stampare la domanda su stderr? Non suona bene. Hai una fonte per questo? Questo vale solo per le applicazioni che hanno prodotto output diversi dalle sole domande e risposte (output che l'utente potrebbe voler convogliare da qualche parte)?

— UTF-8,

@ UTF-8 Il testo della domanda dovrebbe essere considerato parte dell'output del programma? Che dire di ciò che l'utente digita? Non penso che dovrebbe essere (proprio come le conchiglie non pensano che dovrebbe essere). Ma forse dipende dall'applicazione?

— Kusalananda

Grazie per la tua modifica Nel frattempo, ho verificato il comportamento delle applicazioni standard e si comportano come ci si aspetterebbe che si comportino dopo aver letto la risposta.

— UTF-8

@ UTF-8 potresti trovare questo Q&A pertinente: unix.stackexchange.com/q/331611/22222

— terdon

Dalle specifiche POSIX per 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 ).

In altre parole, vanno inseriti errori, informazioni di debug e tutto ciò che rientra nella categoria diagnostica stderr.

Vedere la domanda correlata per ulteriori informazioni: i rapporti sui progressi / le informazioni di registrazione appartengono a stderr o stdout?

— Sergiy Kolodyazhnyy
fonte