Com base nas respostas que recebi (foi difícil escolher uma sobre as outras), não é prejudicial indicar certos tipos de erros usando um código de saída que o Bash também usa. O Bash (ou qualquer outro shell Unix) não fará nada de especial (como executar 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 escrevam scripts shell, eles não especifiquem códigos de saída que já entrem em conflito com códigos de saída predefinidos. em uso, ou seja, eles restringem seus códigos de saída personalizados aos 50 códigos de status disponíveis no intervalo de 64 a 113.
Aprecio a idéia (e a justificativa), mas eu preferiria que o autor fosse mais explícito que não é prejudicial ignorar o conselho - exceto nos casos em que o consumidor de um script está verificando erros, como o exemplo citado de 127 ( command not found)
Especificações POSIX relevantes
Pesquisei o que o POSIX tem a dizer sobre códigos de saída e a especificação do POSIX parece concordar com o autor do Advanced Bash-Scripting Guide. Citei as especificações POSIX relevantes (ênfase minha):
Status de saída para comandos
Cada comando tem um status de saída que pode influenciar o comportamento de outros comandos do shell. O status de saída dos comandos que não são utilitários está documentado nesta seção. O status de saída dos utilitários padrão está documentado em suas respectivas seções.
Se um comando não for encontrado, o status de saída será 127. Se o nome do comando for encontrado, mas não for um utilitário executável, o status de saída será 126. Os aplicativos que chamam utilitários sem usar o shell devem usar esses valores de status de saída para relatar erros semelhantes.
Se um comando falhar durante a expansão ou redirecionamento de palavras, seu status de saída será maior que zero.
Internamente, para fins de decidir se um comando sai com um status de saída diferente de zero, o shell deve reconhecer todo o valor do status recuperado para o comando pelo equivalente à macro WEXITSTATUS da função wait () (conforme definido no volume System Interfaces do POSIX.1-2008). Ao relatar o status de saída com o parâmetro especial '?', O shell deve relatar os oito bits completos do status de saída disponíveis. O status de saída de um comando que foi finalizado porque recebeu um sinal deve ser relatado como superior a 128.
O exitutilitário
Conforme explicado em outras seções, determinados valores de status de saída foram reservados para usos especiais e devem ser usados por aplicativos apenas para esses fins:
126 - Um arquivo a ser executado foi encontrado, mas não era um utilitário executável.127 - Um utilitário a ser executado não foi encontrado.>128 - Um comando foi interrompido por um sinal.
Outras informações
Pelo que vale, pude verificar tudo, exceto um da lista de códigos de saída com significados especiais . Esta tabela de códigos de saída é útil, pois fornece mais detalhes - e exemplos de como gerar os códigos de erro documentados na referência do bash .
Tentativa de gerar o status de saída 128
Usando as versões 3.2.25 e 4.2.46 do Bash, tentei gerar um 128 Invalid argument to exiterro, mas sempre que recebia um 255 (status de saída fora do intervalo). Por exemplo, se exit 3.14159for executado como parte de um script de shell ou em um shell filho interativo, o shell será encerrado com um código de 255:
$ exit 3.14159
exit
bash: exit: 3.14159: numeric argument required
Para ainda mais diversão, eu também tentei executar um programa C simples, mas neste caso, parece que a exit(3)função simplesmente converteu o float em int (3 neste caso) antes de sair:
#include <stdlib.h>
main()
{
exit(3.14159);
}