Czy istnieje sposób, w jaki mogę zrobić to, co podano w tytule poleceń terminalu, czy będę musiał sprawdzić kody?
Czy istnieje sposób, w jaki mogę zrobić to, co podano w tytule poleceń terminalu, czy będę musiał sprawdzić kody?
Odpowiedzi:
Nie ma „przepisu”, aby uzyskać znaczenie statusu wyjścia danej komendy terminalu.
Moja pierwsza próba to strona man:
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).
Po drugie : Google . Zobacz wget jako przykład.
Po trzecie : Stany wyjścia powłoki, na przykład bash. Bash i jego wbudowane funkcje mogą używać wartości powyżej 125 specjalnie. 127 dla polecenia nie znaleziono, 126 dla polecenia nie jest wykonywalny. Aby uzyskać więcej informacji, zobacz kody wyjścia bash .
Kody zakończenia wskazują stan awarii podczas kończenia programu i mieszczą się w zakresie od 0 do 255. Powłoka i jej wbudowane funkcje mogą używać szczególnie wartości powyżej 125 do wskazania określonych trybów awarii, więc lista kodów może się różnić w zależności od powłoki i systemu operacyjnego (np. Bash używa wartości 128 + N jako statusu wyjścia). Patrz: Bash - 3.7.5 Status wyjścia lub man bash.
Ogólnie zerowy status wyjścia wskazuje, że polecenie się powiodło , niezerowy status wyjścia oznacza błąd .
Aby sprawdzić, który kod błędu jest zwracany przez polecenie, możesz wydrukować $?dla ostatniego kodu wyjścia lub ${PIPESTATUS[@]}który podaje listę wartości statusu wyjścia z potoku (w Bash) po wyjściu ze skryptu powłoki.
Nie ma pełnej listy wszystkich kodów wyjścia, które można znaleźć, jednak podjęto próbę usystematyzowania numerów statusu wyjścia w źródle jądra, ale jest to głównie przeznaczone dla programistów C / C ++ i podobny standard skryptowania może być odpowiedni.
Niektóre listy sysexits zarówno w systemie Linux, jak i BSD / OS X z preferowanymi kodami wyjścia dla programów (64-78) można znaleźć w /usr/include/sysexits.h(lub: man sysexitsna 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 */
Powyższa lista przydziela wcześniej nieużywane kody wyjścia z 64-78. Zakres nieprzydzielonych kodów wyjścia będzie dalej ograniczony w przyszłości.
Jednak powyższe wartości są używane głównie w sendmailu i używane przez prawie nikogo innego, więc nie są niczym zbliżonym do standardu (jak wskazuje @Gilles ).
W powłoce status wyjścia jest następujący (na podstawie Bash):
1- 125- Polecenie nie zostało zakończone pomyślnie. Sprawdź stronę podręcznika polecenia pod kątem znaczenia statusu, kilka przykładów poniżej:
1 - Catchall dla ogólnych błędów
Różne błędy, takie jak „dziel przez zero” i inne niedozwolone operacje.
Przykład:
$ let "var1 = 1/0"; echo $?
-bash: let: var1 = 1/0: division by 0 (error token is "0")
1
2 - Niewłaściwe użycie wbudowanych powłok (zgodnie z dokumentacją Bash)
Brakujące słowo kluczowe lub polecenie lub problem z uprawnieniami (i kod powrotu diff przy nieudanym porównaniu pliku binarnego).
Przykład:
empty_function() {}
6 - Brak takiego urządzenia lub adresu
Przykład:
$ curl foo; echo $?
curl: (6) Could not resolve host: foo
6
124 - upłynął limit czasu poleceń
125- jeśli samo polecenie nie powiedzie się, zobacz: coreutils126 - jeśli komenda została znaleziona, ale nie można jej wywołać (np. nie jest wykonywalna)
Problem z uprawnieniami lub polecenie nie jest plikiem wykonywalnym.
Przykład:
$ /dev/null
$ /etc/hosts; echo $?
-bash: /etc/hosts: Permission denied
126
127 - jeśli nie można znaleźć polecenia, proces potomny utworzony w celu jego wykonania zwraca ten status
Możliwy problem z
$PATHliterówką.
Przykład:
$ foo; echo $?
-bash: foo: command not found
127
128 - Nieprawidłowy argument dla exit
Wyjście przyjmuje tylko argumenty całkowite z zakresu 0 - 255.
Przykład:
$ exit 3.14159
-bash: exit: 3.14159: numeric argument required
128- 254- sygnał błędu krytycznego „n” - polecenie wygasło z powodu otrzymania sygnału. Kod sygnału jest dodawany do 128 (128 + SYGNAŁ), aby uzyskać status (Linux man 7 signal:, BSD:) man signal, kilka przykładów poniżej:
130 - polecenie zakończone z powodu naciśnięcia Ctrl-C, 130-128 = 2 (SIGINT)
Przykład:
$ cat
^C
$ echo $?
130
137- jeśli polecenie zostanie wysłane KILL(9)sygnał (128 + 9), w przeciwnym razie status wyjścia polecenia
kill -9 $PPIDskryptu.
141- SIGPIPE- pisz na rurze bez czytnika
Przykład:
$ 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 - komenda zakończona kodem sygnałowym 15 (128 + 15 = 143)
Przykład:
$ sleep 5 && killall sleep &
[1] 19891
$ sleep 100; echo $?
Terminated: 15
143
255* - wyjście ze stanu poza zakresem.
Wyjście przyjmuje tylko argumenty całkowite z zakresu 0 - 255.
Przykład:
$ sh -c 'exit 3.14159'; echo $?
sh: line 0: exit: 3.14159: numeric argument required
255
Zgodnie z powyższą tabelą kody wyjścia 1 - 2, 126 - 165 i 255 mają specjalne znaczenie i dlatego należy ich unikać w przypadku parametrów wyjścia określonych przez użytkownika.
Należy pamiętać, że wartości wyjściowe poza zakresem mogą powodować nieoczekiwane kody wyjścia (np. Wyjście 3809 daje kod wyjścia 225, 3809% 256 = 225).
Widzieć:
errnowartości są używane przez systemowe interfejsy API, nie są używane jako statusy wyjścia (nie są nawet w odpowiednim zakresie) i nie mają znaczenia dla skryptów powłoki. Wartości Sysexits pochodzą z sendmaila i są używane prawie przez nikogo innego, nie są niczym zbliżonym do standardu.
Będziesz musiał zajrzeć do kodu / dokumentacji. Jednak najbardziej zbliżoną do „standaryzacji” jest errno.h
errno.hnie ma znaczenia, jeśli chodzi o kody wyjścia, tylko komunikaty o błędach.
sysexits.h. Jednak niektóre programy zwracają errnos i myślę, że zwracanie errnos ma jak najbardziej sens. Nieobsługiwane errnos rozprzestrzeniają się w górę, jak wyjątki, ( errnopozostaje, funkcje zwracają np. -1Lub 0|NULL). Ponieważ programy są tylko funkcjami, chociaż są one uruchamiane w osobnej przestrzeni adresowej, sensowne jest, aby program mógł kontynuować errnopropagację poza granicami procesu.
"($numeric_code|$bsd_decoded|$errno_plus_one_decoded)".
O ile mi wiadomo, istnieją tylko dwie, mniej więcej, standardowe wartości - obie zdefiniowane w stdlib.hcelu użycia z exit ():
A jedyną de facto standardową wartością, tj. Mającą takie samo znaczenie dla wszystkich programów na świecie, jest 0 (zero), co oznacza SUKCES.
Różne programy wprowadzają różne listy zwracanych kodów „awarii” w celu rozróżnienia lub podkreślenia różnych błędów (różnych typów lub ważności). Niektóre programy używają nawet zwracanej wartości do zgłaszania liczby całkowitej wykrytych błędów środowiska wykonawczego (np. Liczby nieudanych testów jednostkowych w kolorze).
Nie polecałbym wprowadzenia żadnego „nowego standardu” rozszerzającego stdlib.h