Exit code (kod wyjścia, czasem nazywany exit status albo return code) to liczba, którą program zwraca systemowi w momencie zakończenia działania. Umowa jest prosta: 0 oznacza „wszystko poszło dobrze”, a każda wartość niezerowa to sygnał „coś się zepsuło”. To najbardziej podstawowy sposób, w jaki proces komunikuje światu zewnętrznemu, czy zrobił swoje, czy poległ.
Kod wyjścia w systemach uniksowych mieści się w zakresie od 0 do 255 (jeden bajt bez znaku). Jeśli zwrócisz większą liczbę, zostanie ona obcięta modulo 256 — czyli exit 256 w praktyce da 0, a exit 257 da 1. Sam numer nie niesie ze sobą uniwersalnego znaczenia poza zasadą „zero = sukces”: to twórca programu decyduje, że np. 1 to błąd ogólny, a 2 to zły argument wywołania.
Do czego to służy
Exit code jest fundamentem automatyzacji. Skrypty powłoki, systemy CI/CD, cron czy menedżery procesów nie czytają tego, co program wypisuje na ekran — one patrzą na kod wyjścia, żeby zdecydować, co robić dalej. Dzięki temu możesz łączyć polecenia warunkowo: && uruchomi następne polecenie tylko po sukcesie, a || tylko po porażce.
W Bashu kod ostatniego polecenia trzymany jest w zmiennej specjalnej $?. Sprawdzisz go natychmiast po wykonaniu komendy — ale uwaga, kolejne polecenie ją nadpisze, więc jeśli chcesz wartość zachować, przypisz ją od razu do zmiennej.
Przykład z praktyki
Klasyk: szukasz frazy w pliku za pomocą grep i chcesz zareagować na wynik.
grep "ERROR" app.log— gdy znajdzie dopasowanie, zwraca0.- Gdy niczego nie znajdzie, zwraca
1(to nie jest błąd, po prostu „brak trafień”). - Gdy plik nie istnieje albo dostaje zły argument, zwraca
2.
W skrypcie wygląda to tak: if grep -q "ERROR" app.log; then echo "Są błędy"; fi. Tutaj grep nawet nie wypisuje wyniku — liczy się wyłącznie jego kod wyjścia. Podobnie działa to w pipeline’ach Dockera czy GitHub Actions: jeśli krok testów zwróci niezerowy kod, cały build leci na czerwono i deploy się nie wykona.
Na co uważać
Najczęstsza pułapka: zakładanie, że konkretna liczba znaczy to samo w każdym programie. Nie znaczy. 2 w jednym narzędziu to „zły argument”, w innym może być błędem krytycznym. Zaglądaj do dokumentacji (man) danego polecenia.
Druga mina to programy, które zawsze kończą z 0, nawet gdy faktycznie się wywróciły — wtedy automatyzacja myśli, że było super, a w logach pożar. Trzecia rzecz: kody powyżej 128 zwykle oznaczają, że proces został zabity sygnałem — np. 137 to 128 + 9, czyli SIGKILL (często OOM killer), a 130 to przerwanie Ctrl+C.
Pojęcia powiązane: zmienna $?, polecenia exit i return, sygnały (SIGTERM, SIGKILL), strumienie stdout/stderr, operatory && i ||, set -e w Bashu oraz status zadań w CI/CD.