Según las respuestas que recibí (fue difícil elegir una sobre las otras), no es dañino indicar ciertos tipos de errores al usar un código de salida que Bash también usa. Bash (o cualquier otro shell de Unix) no hará nada especial (como ejecutar controladores de excepciones) si una secuencia de comandos de usuario sale con uno de estos códigos de error.
Parece que el autor de la Guía avanzada de secuencias de comandos Bash está de acuerdo con los intentos de BSD de estandarizar los códigos de salida (sysexits.h ) y simplemente recomienda que cuando los usuarios escriben scripts de shell, no especifiquen códigos de salida que ya entren en conflicto con los códigos de salida predefinidos en uso, es decir, restringen sus códigos de salida personalizados a los 50 códigos de estado disponibles en el rango 64-113.
Aprecio la idea (y la justificación) pero hubiera preferido que el autor fuera más explícito que no es dañino ignorar el consejo, aparte de los casos en que el consumidor de un guión está buscando errores, como el ejemplo citado de 127 ( command not found)
Especificaciones POSIX relevantes
Investigué lo que POSIX tiene que decir sobre los códigos de salida y la especificación POSIX parece estar de acuerdo con el autor de la Guía Avanzada de Bash-Scripting. He citado las especificaciones POSIX relevantes (énfasis mío):
Estado de salida para comandos
Cada comando tiene un estado de salida que puede influir en el comportamiento de otros comandos de shell. El estado de salida de los comandos que no son utilidades se documenta en esta sección. El estado de salida de las utilidades estándar está documentado en sus respectivas secciones.
Si no se encuentra un comando, el estado de salida será 127. Si se encuentra el nombre del comando, pero no es una utilidad ejecutable, el estado de salida será 126. Las aplicaciones que invocan utilidades sin usar el shell deben usar estos valores de estado de salida para informar errores similares.
Si un comando falla durante la expansión o redirección de palabras, su estado de salida será mayor que cero.
Internamente, con el fin de decidir si un comando sale con un estado de salida distinto de cero, el shell reconocerá el valor de estado completo recuperado para el comando por el equivalente de la macro WEXITSTATUS de la función wait () (como se define en el volumen de Interfaces del sistema de POSIX.1-2008). Al informar el estado de salida con el parámetro especial '?', El shell informará los ocho bits completos del estado de salida disponibles. El estado de salida de un comando que finalizó porque recibió una señal se informará como mayor que 128.
La exitutilidad
Como se explicó en otras secciones, ciertos valores de estado de salida se han reservado para usos especiales y las aplicaciones deben usarlos solo para esos fines:
126 - Se encontró un archivo a ejecutar, pero no era una utilidad ejecutable.127 - No se encontró una utilidad para ejecutar.>128 - Un comando fue interrumpido por una señal.
Más información
Por lo que vale, pude verificar todos menos uno de la lista de Códigos de salida con significados especiales . Esta tabla de códigos de salida es útil ya que proporciona más detalles y ejemplos de cómo generar los códigos de error documentados en la referencia de Bash .
Intenta generar un estado de salida de 128
Usando las versiones Bash 3.2.25 y 4.2.46, traté de arrojar un 128 Invalid argument to exiterror, pero cada vez que recibí un 255 (estado de salida fuera de rango). Por ejemplo, si exit 3.14159se ejecuta como parte de un script de shell o en un shell secundario interactivo, el shell sale con un código de 255:
$ exit 3.14159
exit
bash: exit: 3.14159: numeric argument required
Para divertirme aún más, también intenté ejecutar un programa C simple, pero en este caso, parece que la exit(3)función simplemente convirtió el flotador en int (3 en este caso) antes de salir:
#include <stdlib.h>
main()
{
exit(3.14159);
}