W oparciu o odpowiedzi, które otrzymałem (trudno było wybrać jedną z pozostałych), wskazanie pewnych rodzajów błędów przy użyciu kodu wyjścia, którego używa Bash , nie jest szkodliwe . Bash (lub jakakolwiek inna powłoka uniksowa) nie zrobi nic specjalnego (takiego jak uruchamianie programów obsługi wyjątków), jeśli skrypt użytkownika zakończy działanie z jednym z tych kodów błędów.
Wygląda na to, że autor Advanced Bash-Scripting Guide zgadza się z próbami standaryzacji kodów wyjścia ( sysexits.h) przez BSD i po prostu zaleca, aby użytkownicy piszący skrypty powłoki nie podawali już kodów wyjścia, które są w konflikcie ze wstępnie zdefiniowanymi kodami wyjścia w użyciu, tj. ograniczają swoje niestandardowe kody wyjścia do 50 dostępnych kodów stanu z zakresu 64-113.
Doceniam pomysł (i uzasadnienie), ale wolałbym, gdyby autor był bardziej wyraźny, że ignorowanie porady nie jest szkodliwe - oprócz przypadków, w których konsument skryptu sprawdza błędy, takie jak cytowany przykład 127 ( command not found).
Odpowiednie specyfikacje POSIX
Zbadałem, co POSIX ma do powiedzenia na temat kodów wyjścia, a specyfikacja POSIX wydaje się zgadzać z autorem Advanced Bash-Scripting Guide. Przytoczyłem odpowiednie specyfikacje POSIX (moje wyróżnienie):
Status wyjścia dla poleceń
Każde polecenie ma status wyjścia, który może wpływać na zachowanie innych poleceń powłoki. Status wyjścia komend, które nie są narzędziami, jest udokumentowany w tej sekcji. Status wyjścia standardowych narzędzi jest udokumentowany w odpowiednich sekcjach.
Jeśli polecenie nie zostanie znalezione, stanem wyjścia będzie 127. Jeśli nazwa polecenia zostanie znaleziona, ale nie jest to narzędzie wykonywalne, stanem wyjścia będzie 126. Aplikacje, które wywołują narzędzia bez użycia powłoki, powinny używać tych wartości statusu wyjścia zgłaszać podobne błędy.
Jeżeli polecenie nie powiedzie się podczas rozwijania lub przekierowywania słów, jego status wyjścia powinien być większy niż zero.
Wewnętrznie, w celu podjęcia decyzji, czy polecenie kończy działanie z niezerowym statusem wyjścia, powłoka rozpoznaje całą wartość statusu pobraną dla polecenia przez odpowiednik makra funkcji WEXITSTATUS funkcji wait () zdefiniowanego w objętości interfejsów systemowych POSIX.1-2008). Zgłaszając status wyjścia za pomocą specjalnego parametru „?”, Powłoka zgłasza pełne osiem dostępnych bitów statusu wyjścia. Status wyjścia polecenia, które zakończyło się, ponieważ odebrał sygnał, zgłasza się jako większy niż 128.
exitużyteczność
Jak wyjaśniono w innych sekcjach, niektóre wartości statusu wyjścia zostały zarezerwowane do specjalnych zastosowań i powinny być używane przez aplikacje tylko do tych celów:
126 - Znaleziono plik do wykonania, ale nie był to program wykonywalny.127 - Nie znaleziono narzędzia do wykonania.>128 - Polecenie zostało przerwane sygnałem.
Dalsza informacja
Z tego, co warto, udało mi się zweryfikować wszystkie kody wyjścia poza specjalnymi znaczeniami oprócz jednego . Ta tabela kodów wyjścia jest przydatna, ponieważ zawiera więcej szczegółów - i przykłady generowania kodów błędów udokumentowanych w odnośniku Bash .
Próba wygenerowania statusu wyjścia 128
Korzystając z wersji Bash 3.2.25 i 4.2.46, próbowałem wyrzucić 128 Invalid argument to exitbłąd, ale za każdym razem otrzymywałem 255 (Status wyjścia poza zakresem). Na przykład, jeśli exit 3.14159jest wykonywany jako część skryptu powłoki lub w interaktywnej powłoce podrzędnej, powłoka kończy działanie z kodem 255:
$ exit 3.14159
exit
bash: exit: 3.14159: numeric argument required
Dla jeszcze większej zabawy próbowałem również uruchomić prosty program w C, ale w tym przypadku wydaje się, że exit(3)funkcja po prostu przekształciła liczbę zmiennoprzecinkową na int (w tym przypadku 3) przed wyjściem:
#include <stdlib.h>
main()
{
exit(3.14159);
}