Kiedy używać standardowego strumienia błędów w aplikacji wiersza poleceń?

Czy istnieją wytyczne, kiedy należy użyć błędu podczas pisania aplikacji wiersza polecenia? Ku mojemu zdziwieniu, nie znalazłem niczego, przeglądając go w Google.

W szczególności pytanie, które mnie teraz interesuje, brzmi: czy użyć stdoutlub stderrkiedy użytkownik wywołał program z nielegalnymi argumentami. Jednak bardziej doceniana jest bardziej kompleksowa odpowiedź, ponieważ z pewnością nie będzie to jedyny przypadek, w którym do napisania programu zachowującego się w sposób zgodny z oczekiwaniami użytkownika potrzebna jest jasna reguła.

Tak, wyświetlaj komunikat, stderrgdy używane są nieprawidłowe argumenty. A jeśli spowoduje to również zamknięcie aplikacji, wyjdź z niezerowym statusem wyjścia.

Powinieneś używać standardowego strumienia błędów do komunikatów diagnostycznych lub interakcji użytkownika. Komunikaty diagnostyczne obejmują komunikaty o błędach, ostrzeżenia i inne komunikaty, które nie są częścią danych wyjściowych narzędzia, gdy działa ono poprawnie („poprawnie” oznacza, że ​​nie dzieje się nic wyjątkowego, na przykład nie znaleziono plików lub cokolwiek to może być).

Wiele powłok (wszystkie?) Wyświetla monity, typy użytkowników, menu itp. stderr, Aby przekierowanie stdoutnie powstrzymało cię od interakcji z powłoką w znaczący sposób.

Poniżej znajduje się post z bloga na ten temat:

To cytat Douga McIllroya, wynalazcy rur uniksowych, wyjaśniający, jak to się stderrstało. „v6” odnosi się do wersji określonej wersji oryginalnego systemu operacyjnego Unix, która została wydana w 1975 r.

Wszystkie programy umieściły diagnostykę na standardowym wyjściu. Zawsze powodowało to problemy, gdy dane wyjściowe były przekierowywane do pliku, ale stawały się nie do zniesienia, gdy dane wyjściowe były wysyłane do niczego niepodejrzewającego procesu. Niemniej jednak, nie chcąc naruszać prostoty standardowego modelu wejścia-standardu-wyjścia, ludzie tolerowali ten stan rzeczy poprzez wersję 6. Niedługo potem Dennis Ritchie odciął węzeł gordyjski, wprowadzając standardowy plik błędu. To nie wystarczyło. W przypadku potoków diagnostyka może pochodzić z kilku programów działających jednocześnie. Diagnostyka potrzebna do identyfikacji.
- Doug McIllroy, „A Research UNIX Reader: Annotated Excerpts from the Programmer's Manual, 1971-1986”

„Identyfikacja siebie” oznacza po prostu powiedzenie „Hej! To ja mówię! To poszło nie tak: [...]”:

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

Robi to na stderrkorzystne, gdyż w przeciwnym razie może to być odczytane przez co czytałem na stdout(ale nie rób tego przy lskażdym razie , prawda?).

Ze specyfikacji POSIX dla standardowych strumieni:

Podczas uruchamiania programu należy wstępnie zdefiniować trzy strumienie i nie trzeba ich jawnie otwierać: standardowe wejście (do odczytu konwencjonalnego wejścia), standardowe wyjście (do zapisu konwencjonalnego wyjścia) i standardowy błąd (do zapisu wyjścia diagnostycznego ).

Innymi słowy, błędy, informacje debugowania i wszystko, co należy do kategorii diagnostycznej, obejmuje stderr.

Zobacz podobne pytanie, aby uzyskać więcej informacji: czy raporty postępu / informacje o logowaniu należą do stderr czy stdout?