Respuestas:
No existe una "receta" para obtener el significado de un estado de salida de un comando de terminal dado.
Mi primer intento sería la página de manual:
user@host:~# man ls
Exit status:
0 if OK,
1 if minor problems (e.g., cannot access subdirectory),
2 if serious trouble (e.g., cannot access command-line argument).
Segundo : Google . Ver wget como un ejemplo.
Tercero : los estados de salida del shell, por ejemplo bash. Bash y sus componentes incorporados pueden usar valores superiores a 125 especialmente. 127 para comando no encontrado, 126 para comando no ejecutable. Para obtener más información, consulte los códigos de salida de bash .
Los códigos de salida indican una condición de falla al finalizar un programa y caen entre 0 y 255. El shell y sus componentes incorporados pueden usar especialmente los valores superiores a 125 para indicar modos de falla específicos, por lo que la lista de códigos puede variar entre shells y sistemas operativos (por ejemplo, Bash usa el valor 128 + N como el estado de salida). Ver: Bash - 3.7.5 Estado de salida o man bash.
En general, un estado de salida cero indica que un comando tuvo éxito , un estado de salida distinto de cero indica un error .
Para verificar qué código de error devuelve el comando, puede imprimir $?para el último código de salida o ${PIPESTATUS[@]}que proporciona una lista de valores de estado de salida de la canalización (en Bash) después de que sale un script de shell.
No hay una lista completa de todos los códigos de salida que se pueden encontrar, sin embargo, se ha intentado sistematizar los números de estado de salida en la fuente del núcleo, pero esto está destinado principalmente a los programadores de C / C ++ y un estándar similar para las secuencias de comandos podría ser apropiado.
Puede encontrar alguna lista de sysexits en Linux y BSD / OS X con códigos de salida preferibles para programas (64-78) en /usr/include/sysexits.h(o: man sysexitsen BSD):
0 /* successful termination */
64 /* base value for error messages */
64 /* command line usage error */
65 /* data format error */
66 /* cannot open input */
67 /* addressee unknown */
68 /* host name unknown */
69 /* service unavailable */
70 /* internal software error */
71 /* system error (e.g., can't fork) */
72 /* critical OS file missing */
73 /* can't create (user) output file */
74 /* input/output error */
75 /* temp failure; user is invited to retry */
76 /* remote error in protocol */
77 /* permission denied */
78 /* configuration error */
/* maximum listed value */
La lista anterior asigna códigos de salida previamente no utilizados de 64-78. El rango de códigos de salida no asignados se restringirá aún más en el futuro.
Sin embargo, los valores anteriores se usan principalmente en sendmail y casi nadie los usa, por lo que no son nada remotamente cercanos a un estándar (como lo señaló @Gilles ).
En shell, el estado de salida es el siguiente (basado en Bash):
1- 125- El comando no se completó correctamente. Consulte la página del comando man para ver el significado del estado, algunos ejemplos a continuación:
1 - Catchall para errores generales
Errores varios, como "dividir por cero" y otras operaciones no permitidas.
Ejemplo:
$ let "var1 = 1/0"; echo $?
-bash: let: var1 = 1/0: division by 0 (error token is "0")
1
2 - Uso indebido de los componentes integrados de shell (según la documentación de Bash)
Falta la palabra clave o el comando, o el problema de permiso (y el código de retorno de diferencias en una comparación de archivo binario fallida)
Ejemplo:
empty_function() {}
6 - No existe tal dispositivo o dirección
Ejemplo:
$ curl foo; echo $?
curl: (6) Could not resolve host: foo
6
124 - el tiempo de espera del comando
125- Si un comando en sí falla, vea: coreutils126 - si se encuentra el comando pero no se puede invocar (por ejemplo, no es ejecutable)
El problema o el comando de permiso no es un ejecutable.
Ejemplo:
$ /dev/null
$ /etc/hosts; echo $?
-bash: /etc/hosts: Permission denied
126
127 - si no se puede encontrar un comando, el proceso hijo creado para ejecutarlo devuelve ese estado
Posible problema con
$PATHo un error tipográfico.
Ejemplo:
$ foo; echo $?
-bash: foo: command not found
127
128 - Argumento no válido para exit
exit solo toma argumentos enteros en el rango de 0 a 255.
Ejemplo:
$ exit 3.14159
-bash: exit: 3.14159: numeric argument required
128- 254- señal de error fatal "n" - el comando murió debido a la recepción de una señal. El código de señal se agrega a 128 (128 + SEÑAL) para obtener el estado (Linux:, man 7 signalBSD:) man signal, algunos ejemplos a continuación:
130 - comando terminado debido a que se presionó Ctrl-C, 130-128 = 2 (SIGINT)
Ejemplo:
$ cat
^C
$ echo $?
130
137- si se envía la KILL(9)señal al comando (128 + 9), el estado de salida del comando de lo contrario
kill -9 $PPIDde guión.
141- SIGPIPE- escriba en una tubería sin lector
Ejemplo:
$ hexdump -n100000 /dev/urandom | tee &>/dev/null >(cat > file1.txt) >(cat > file2.txt) >(cat > file3.txt) >(cat > file4.txt) >(cat > file5.txt)
$ find . -name '*.txt' -print0 | xargs -r0 cat | tee &>/dev/null >(head /dev/stdin > head.out) >(tail /dev/stdin > tail.out)
xargs: cat: terminated by signal 13
$ echo ${PIPESTATUS[@]}
0 125 141
143 - comando terminado por el código de señal 15 (128 + 15 = 143)
Ejemplo:
$ sleep 5 && killall sleep &
[1] 19891
$ sleep 100; echo $?
Terminated: 15
143
255* - estado de salida fuera de rango.
exit solo toma argumentos enteros en el rango de 0 a 255.
Ejemplo:
$ sh -c 'exit 3.14159'; echo $?
sh: line 0: exit: 3.14159: numeric argument required
255
De acuerdo con la tabla anterior, los códigos de salida 1 - 2, 126 - 165 y 255 tienen significados especiales y, por lo tanto, deben evitarse para los parámetros de salida especificados por el usuario.
Tenga en cuenta que los valores de salida fuera de rango pueden generar códigos de salida inesperados (por ejemplo, la salida 3809 proporciona un código de salida de 225, 3809% 256 = 225).
Ver:
errnolos valores son utilizados por las API del sistema, no se usan como estados de salida (ni siquiera están en el rango correcto) y son irrelevantes para las secuencias de comandos de shell. Los valores de Sysexits son de sendmail y son utilizados por prácticamente nadie más, no son nada remotamente cercanos a un estándar.
Tendrá que buscar en el código / documentación. Sin embargo, lo que más se acerca a una "estandarización" es errno.h
errno.hes irrelevante cuando se trata de códigos de salida, solo mensajes de error.
sysexits.h. Sin embargo, algunos programas devuelven errnos, y realmente creo que devolver errnos tiene más sentido. Los errnos no manejados se propagan hacia arriba, como excepciones, (las errnoestancias, las funciones regresan, por ejemplo, -1o 0|NULL). Dado que los programas son solo funciones, aunque las funciones se ejecutan en un espacio de direcciones separado, tiene sentido que un programa desee continuar la errnopropagación a través del límite del proceso.
"($numeric_code|$bsd_decoded|$errno_plus_one_decoded)".
Hasta donde sé, solo hay dos valores estándar, más o menos, ambos definidos stdlib.hpara usar con exit ():
Y el único valor estándar de facto, es decir, que tiene el mismo significado para todos los programas en el mundo, es 0 (cero) que significa ÉXITO.
Los diferentes programas introducen diferentes listas de códigos de "falla" devueltos para distinguir o enfatizar diferentes errores (diferentes tipos o severidad). Algunos programas incluso usan el valor devuelto para informar el número entero de errores de tiempo de ejecución descubiertos (por ejemplo, el número de pruebas unitarias fallidas en la demanda).
No recomendaría introducir ningún tipo de "nuevo estándar" que extienda el stdlib.h