Przechwytywanie kodów błędów w rurze powłoki

Obecnie mam skrypt, który robi coś takiego

./a | ./b | ./c

Chcę go zmodyfikować, aby w przypadku wyjścia a, b lub c z kodem błędu wydrukowałem komunikat o błędzie i zatrzymałem się zamiast przesyłać do przodu złe wyjście.

Jaki byłby najprostszy / najczystszy sposób, aby to zrobić?

Jeśli naprawdę nie chcesz, aby drugie polecenie było kontynuowane, dopóki pierwsze nie zakończy się sukcesem, prawdopodobnie musisz użyć plików tymczasowych. Prosta wersja to:

tmp=${TMPDIR:-/tmp}/mine.$$
if ./a > $tmp.1
then
    if ./b <$tmp.1 >$tmp.2
    then
        if ./c <$tmp.2
        then : OK
        else echo "./c failed" 1>&2
        fi
    else echo "./b failed" 1>&2
    fi
else echo "./a failed" 1>&2
fi
rm -f $tmp.[12]

Przekierowanie „1> & 2” można również skrócić „> & 2”; jednak stara wersja powłoki MKS błędnie radziła sobie z przekierowaniem błędu bez poprzedzającej je cyfry „1”, więc od wieków używam tej jednoznacznej notacji dla zapewnienia niezawodności.

To powoduje wyciek plików, jeśli coś przerwiesz. Programowanie pocisków odpornych na bomby (mniej lub bardziej) wykorzystuje:

tmp=${TMPDIR:-/tmp}/mine.$$
trap 'rm -f $tmp.[12]; exit 1' 0 1 2 3 13 15
...if statement as before...
rm -f $tmp.[12]
trap 0 1 2 3 13 15

Pierwsza linia pułapki mówi „uruchom komendy” rm -f $tmp.[12]; exit 1, gdy wystąpi którykolwiek z sygnałów 1 SIGHUP, 2 SIGINT, 3 SIGQUIT, 13 SIGPIPE lub 15 SIGTERM, lub 0 (gdy powłoka kończy pracę z dowolnego powodu). Jeśli piszesz skrypt powłoki, ostatnia pułapka musi tylko usunąć pułapkę na 0, która jest pułapką wyjściową powłoki (możesz pozostawić inne sygnały na miejscu, ponieważ proces i tak wkrótce się zakończy).

W pierwotnym potoku możliwe jest, że „c” będzie czytać dane z „b” przed zakończeniem „a” - jest to zwykle pożądane (na przykład daje wiele rdzeni do wykonania). Jeśli „b” jest fazą „sortowania”, to nie ma to zastosowania - „b” musi zobaczyć wszystkie swoje dane wejściowe, zanim będzie mógł wygenerować jakiekolwiek dane wyjściowe.

Jeśli chcesz wykryć, które polecenia zawodzą, możesz użyć:

(./a || echo "./a exited with $?" 1>&2) |
(./b || echo "./b exited with $?" 1>&2) |
(./c || echo "./c exited with $?" 1>&2)

Jest to proste i symetryczne - trywialne jest rozszerzenie do potoku 4-częściowego lub N-częściowego.

Proste eksperymentowanie z „set -e” nie pomogło.

W bashu możesz użyć set -ei set -o pipefailna początku pliku. Kolejne polecenie ./a | ./b | ./czakończy się niepowodzeniem, gdy zawiedzie którykolwiek z trzech skryptów. Kod powrotu będzie kodem powrotu pierwszego skryptu, który zakończył się niepowodzeniem.

Pamiętaj, że pipefailnie jest dostępny w standardowym sh .

Możesz też sprawdzić ${PIPESTATUS[]}tablicę po pełnym wykonaniu, np. Jeśli uruchomisz:

./a | ./b | ./c

Następnie ${PIPESTATUS}pojawi się tablica kodów błędów z każdego polecenia w potoku, więc jeśli środkowe polecenie zawiodło, echo ${PIPESTATUS[@]}zawierałoby coś takiego:

0 1 0

i coś takiego wykonujemy po poleceniu:

test ${PIPESTATUS[0]} -eq 0 -a ${PIPESTATUS[1]} -eq 0 -a ${PIPESTATUS[2]} -eq 0

pozwoli ci sprawdzić, czy wszystkie polecenia w potoku powiodły się.

Niestety, odpowiedź Johnathana wymaga plików tymczasowych, a odpowiedzi Michela i Imrona wymagają basha (mimo że to pytanie jest oznaczone jako powłoka). Jak już zauważyli inni, nie jest możliwe przerwanie potoku przed rozpoczęciem późniejszych procesów. Wszystkie procesy są uruchamiane od razu i dlatego będą działać, zanim będzie można zgłosić jakiekolwiek błędy. Ale tytuł pytania dotyczył również kodów błędów. Można je odzyskać i zbadać po zakończeniu rury, aby ustalić, czy którykolwiek z zaangażowanych procesów zawiódł.

Oto rozwiązanie, które wyłapuje wszystkie błędy w rurze, a nie tylko błędy ostatniego komponentu. Tak to jest jak pipefail atakujących, tuż mocniejsze w tym sensie, że można odzyskać wszystkie kody błędów.

res=$( (./a 2>&1 || echo "1st failed with $?" >&2) |
(./b 2>&1 || echo "2nd failed with $?" >&2) |
(./c 2>&1 || echo "3rd failed with $?" >&2) > /dev/null 2>&1)
if [ -n "$res" ]; then
    echo pipe failed
fi

Aby wykryć, czy coś nie powiodło, echopolecenie wypisuje na standardowym wyjściu błędów w przypadku dowolnego polecenia nie powiedzie się. Następnie połączone standardowe wyjście błędów jest zapisywane $resi analizowane później. Dlatego też standardowy błąd wszystkich procesów jest przekierowywany na standardowe wyjście. Możesz również wysłać te dane wyjściowe /dev/nulllub pozostawić je jako kolejny wskaźnik, że coś poszło nie tak. Możesz zastąpić ostatnie przekierowanie /dev/nullplikiem, jeśli nie chcesz przechowywać danych wyjściowych ostatniego polecenia w dowolnym miejscu.

Aby grać więcej z tego konstruktu i przekonać się, że to naprawdę robi to, co powinien, wymieniłem ./a, ./ba ./cprzez podpowłok, które wykonują echo, catoraz exit. Możesz użyć tego, aby sprawdzić, czy ta konstrukcja rzeczywiście przekazuje wszystkie dane wyjściowe z jednego procesu do drugiego i czy kody błędów są poprawnie rejestrowane.

res=$( (sh -c "echo 1st out; exit 0" 2>&1 || echo "1st failed with $?" >&2) |
(sh -c "cat; echo 2nd out; exit 0" 2>&1 || echo "2nd failed with $?" >&2) |
(sh -c "echo start; cat; echo end; exit 0" 2>&1 || echo "3rd failed with $?" >&2) > /dev/null 2>&1)
if [ -n "$res" ]; then
    echo pipe failed
fi