Sim, exiba uma mensagem em stderr
quando os argumentos errados forem usados. E se isso também fizer com que o aplicativo saia, saia com status de saída diferente de zero.
Você deve usar o fluxo de erro padrão para mensagens de diagnóstico . As mensagens de diagnóstico incluem mensagens de erro, avisos e outras mensagens que não fazem parte da saída do utilitário quando estão funcionando corretamente ("corretamente", significando que não há nada de excepcional acontecendo, como arquivos não encontrados ou o que for).
Muitos shells (todos?) exibem prompts, o que o usuário digita e menus etc. em stderr
, de modo que redirecionar stdout
não o impeça de interagir com o shell de maneira significativa.
O que se segue é de uma publicação no blog sobre este tema:
This is a quote from Doug McIllroy, inventor of Unix pipes, explaining how
stderr
came to be. 'v6' is referring to a version of specific version of the original Unix operating system that was released in 1975.All programs placed diagnostics on the standard output. This had always caused trouble when the output was redirected into a file, but became intolerable when the output was sent to an unsuspecting process. Nevertheless, unwilling to violate the simplicity of the standard-input-standard-output model, people tolerated this state of affairs through v6. Shortly thereafter Dennis Ritchie cut the Gordian knot by introducing the standard error file. That was not quite enough. With pipelines diagnostics could come from any of several programs running simultaneously. Diagnostics needed to identify themselves.
-- Doug McIllroy, "A Research UNIX Reader: Annotated Excerpts from the Programmer’s Manual, 1971-1986"
"identificar-se" significa simplesmente dizer "Ei! Sou eu falando! Isso deu errado: [...]":
$ ls nothere
ls: nothere: No such file or directory
É preferível fazer isso em stderr
, pois, caso contrário, poderia ser lido pelo que estava lendo em stdout
(mas nós não fazemos isso com ls
de qualquer maneira , não é?).