Exit code

Liczbowy status zwracany przez program po zakończeniu – 0 oznacza sukces, wartości niezerowe błąd. Skrypty wykorzystują go do sprawdzania, czy polecenie się powiodło.

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, zwraca 0.
  • 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.