Risposte:
Non esiste una "ricetta" per ottenere i significati di uno stato di uscita di un dato comando terminale.
Il mio primo tentativo sarebbe la manpage:
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).
Secondo : Google . Vedi wget come esempio.
Terzo : gli stati di uscita della shell, ad esempio bash. Bash e i suoi builtins possono usare valori superiori a 125 appositamente. 127 per comando non trovato, 126 per comando non eseguibile. Per ulteriori informazioni, consultare i codici di uscita bash .
I codici di uscita indicano una condizione di errore quando si termina un programma e cadono tra 0 e 255. La shell e i suoi builtin possono usare specialmente i valori sopra 125 per indicare specifiche modalità di errore, quindi l'elenco dei codici può variare tra shell e sistemi operativi (es. Bash utilizza il valore 128 + N come stato di uscita). Vedere: Bash - 3.7.5 Stato uscita o man bash.
In generale uno stato di uscita zero indica che un comando ha avuto esito positivo , uno stato di uscita diverso da zero indica un errore .
Per verificare quale codice di errore viene restituito dal comando, è possibile stampare $?per l'ultimo codice di uscita o ${PIPESTATUS[@]}che fornisce un elenco di valori dello stato di uscita dalla pipeline (in Bash) dopo la chiusura di uno script della shell.
Non è possibile trovare un elenco completo di tutti i codici di uscita, tuttavia si è tentato di sistematizzare i numeri dello stato di uscita nel sorgente del kernel, ma questo è principalmente destinato ai programmatori C / C ++ e standard simili per gli script potrebbero essere appropriati.
Un elenco di sysexit su Linux e BSD / OS X con codici di uscita preferibili per i programmi (64-78) è disponibile in /usr/include/sysexits.h(o: man sysexitssu 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 */
L'elenco precedente assegna codici di uscita precedentemente inutilizzati da 64 a 78. La gamma di codici di uscita non assegnati sarà ulteriormente limitata in futuro.
Tuttavia i valori di cui sopra sono principalmente usati in sendmail e usati praticamente da nessun altro, quindi non sono nulla lontanamente vicino a uno standard (come indicato da @Gilles ).
Nella shell lo stato di uscita è il seguente (basato su Bash):
1- 125- Il comando non è stato completato correttamente. Controlla la pagina man del comando per il significato dello stato, alcuni esempi di seguito:
1 - Catchall per errori generali
Errori vari, come "dividi per zero" e altre operazioni non consentite.
Esempio:
$ let "var1 = 1/0"; echo $?
-bash: let: var1 = 1/0: division by 0 (error token is "0")
1
2 - Uso improprio dei builtin della shell (secondo la documentazione di Bash)
Parola chiave o comando mancante o problema di autorizzazione (e codice di ritorno diff su un confronto di file binario non riuscito).
Esempio:
empty_function() {}
6 - Nessun dispositivo o indirizzo
Esempio:
$ curl foo; echo $?
curl: (6) Could not resolve host: foo
6
124 - timeout del comando
125- se un comando stesso non riesce, vedere: coreutils126 - se il comando viene trovato ma non può essere richiamato (ad es. non è eseguibile)
Il problema o il comando di autorizzazione non è un eseguibile.
Esempio:
$ /dev/null
$ /etc/hosts; echo $?
-bash: /etc/hosts: Permission denied
126
127 - se non è possibile trovare un comando, il processo figlio creato per eseguirlo restituisce tale stato
Possibile problema con
$PATHo un refuso.
Esempio:
$ foo; echo $?
-bash: foo: command not found
127
128 - Argomento non valido per exit
exit accetta solo argomenti interi nell'intervallo 0 - 255.
Esempio:
$ exit 3.14159
-bash: exit: 3.14159: numeric argument required
128- 254- segnale di errore fatale "n" - il comando è morto a causa della ricezione di un segnale. Il codice del segnale viene aggiunto a 128 (128 + SIGNAL) per ottenere lo stato (Linux man 7 signal:, BSD:) man signal, alcuni esempi di seguito:
130 - comando terminato a causa della pressione di Ctrl-C, 130-128 = 2 (SIGINT)
Esempio:
$ cat
^C
$ echo $?
130
137- se al comando viene inviato il KILL(9)segnale (128 + 9), lo stato di uscita del comando altrimenti
kill -9 $PPIDdi sceneggiatura.
141- SIGPIPE- scrivere su una pipe senza lettore
Esempio:
$ 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 terminato dal codice segnale 15 (128 + 15 = 143)
Esempio:
$ sleep 5 && killall sleep &
[1] 19891
$ sleep 100; echo $?
Terminated: 15
143
255* - esce dallo stato fuori intervallo.
exit accetta solo argomenti interi nell'intervallo 0 - 255.
Esempio:
$ sh -c 'exit 3.14159'; echo $?
sh: line 0: exit: 3.14159: numeric argument required
255
Secondo la tabella sopra, i codici di uscita 1 - 2, 126 - 165 e 255 hanno significati speciali e dovrebbero quindi essere evitati per i parametri di uscita specificati dall'utente.
Si noti che i valori di uscita fuori intervallo possono comportare codici di uscita imprevisti (ad esempio, l'uscita 3809 fornisce un codice di uscita di 225, 3809% 256 = 225).
Vedere:
errnoi valori vengono utilizzati dalle API di sistema, non vengono utilizzati come stati di uscita (non sono nemmeno nell'intervallo corretto) e sono irrilevanti per gli script di shell. I valori di Sysexits provengono da sendmail e non sono usati praticamente da nessun altro, non sono nulla in remoto vicino a uno standard.
Dovrai esaminare il codice / la documentazione. Tuttavia, la cosa che si avvicina di più a una "standardizzazione" è errno.h
errno.hè irrilevante quando si tratta di codici di uscita, solo messaggi di errore.
sysexits.h. Tuttavia, alcuni programmi restituiscono errnos, e in realtà penso che restituire errnos abbia più senso. I non gestiti si errnopropagano verso l'alto, come le eccezioni (i errnosoggiorni, le funzioni ritornano ad es. -1Oppure 0|NULL). Poiché i programmi sono solo funzioni, sebbene funzioni che vengono eseguite in uno spazio di indirizzi separato, ha senso che un programma potrebbe voler continuare la errnopropagazione oltre il limite del processo.
"($numeric_code|$bsd_decoded|$errno_plus_one_decoded)".
Per quanto ne so, ci sono solo due valori, più o meno standard, entrambi definiti stdlib.hper l'uso con exit ():
E l'unico valore standard di fatto, ovvero con lo stesso significato per tutti i programmi del mondo, è 0 (zero) che sta per SUCCESSO.
Programmi diversi introducono elenchi diversi di codici di "errore" restituiti per distinguere o enfatizzare errori diversi (tipi o gravità diversi). Alcuni programmi utilizzano persino il valore restituito per riportare il numero intero di errori di runtime rilevati (ad es. Il numero di unit test non riusciti nel seme).
Non consiglierei di introdurre alcun tipo di "nuovo standard" estendendo il stdlib.h