Com base nas respostas que recebi (foi difícil escolher uma sobre as outras), não é prejudicial indicar determinados tipos de erros usando um código de saída que o Bash também usa . Bash (ou qualquer outro shell Unix) não fará nada de especial (como a execução de manipuladores de exceção) se um script de usuário sair com um desses códigos de erro.
Parece que o autor do Advanced Bash-Scripting Guide concorda com as tentativas do BSD de padronizar os códigos de saída ( sysexits.h ) e está simplesmente recomendando que quando os usuários escrevem scripts shell, eles não • especificar códigos de saída que entrem em conflito com códigos de saída predefinidos já em uso, isto é, eles restringem seus códigos de saída personalizados aos 50 códigos de status disponíveis no intervalo 64-113.
Eu aprecio a idéia (e a lógica), mas preferia que o autor fosse mais explícito que não é prejudicial ignorar o conselho - além de casos em que o consumidor de um script está verificando erros como os citados exemplo de 127 ( command not found ).
Especificações POSIX relevantes
Eu pesquisei o que POSIX tem a dizer sobre códigos de saída e a especificação POSIX parece concordar com o autor do Advanced Bash-Scripting Guide. Eu citei as especificações POSIX relevantes (ênfase minha):
Sair do status dos comandos
Each command has an exit status that can influence the behavior of other shell commands. The exit status of commands that are not utilities is documented in this section. The exit status of the standard utilities is documented in their respective sections.
If a command is not found, the exit status shall be 127. If the command name is found, but it is not an executable utility, the exit status shall be 126. Applications that invoke utilities without using the shell should use these exit status values to report similar errors.
If a command fails during word expansion or redirection, its exit status shall be greater than zero.
Internally, for purposes of deciding whether a command exits with a non-zero exit status, the shell shall recognize the entire status value retrieved for the command by the equivalent of the wait() function WEXITSTATUS macro (as defined in the System Interfaces volume of POSIX.1-2008). When reporting the exit status with the special parameter '?', the shell shall report the full eight bits of exit status available. The exit status of a command that terminated because it received a signal shall be reported as greater than 128.
O utilitário exit
As explained in other sections, certain exit status values have been reserved for special uses and should be used by applications only for those purposes:
-
126 – A file to be executed was found, but it was not an executable utility.
-
127 – A utility to be executed was not found.
-
>128 – A command was interrupted by a signal.
Mais informações
Por que vale a pena, eu consegui verificar todos, exceto um, da lista de Códigos de saída com especial Significados . Esta tabela de códigos de saída é útil, pois fornece mais detalhes - e exemplos de como gerar os códigos de erro documentados no Referência de bash .
Tentativa de gerar status de saída de 128
Usando as versões 3.2.25 e 4.2.46 do Bash, tentei lançar um erro 128 Invalid argument to exit , mas cada vez que recebi um 255 (status de saída fora do intervalo). Por exemplo, se exit 3.14159 for executado como parte de um script shell ou em um shell filho interativo, o shell sairá com um código 255 :
$ exit 3.14159
exit
bash: exit: 3.14159: numeric argument required
Para ainda mais divertido, eu também tentei executar um programa C simples, mas neste caso, parece que a função exit(3) simplesmente converteu o float para um int (3 neste caso) antes de sair:
#include <stdlib.h>
main()
{
exit(3.14159);
}