Program Bash nie zostanie wykonany, jeśli przekierowanie nie powiedzie się

W bash zauważam, że jeśli polecenie korzystające z przekierowania nie powiedzie się, wszystkie programy, które działają wcześniej, nie zostaną uruchomione.

Na przykład ten program otwiera plik „a” i zapisuje 50 bajtów w pliku „a”. Jednak uruchomienie tego polecenia z przekierowaniem do pliku o niewystarczających uprawnieniach (~ root / log) nie powoduje zmiany rozmiaru pliku „a”.

$ ./write_file.py >> ~root/log
-bash: /var/root/log: Permission denied
cdal at Mac in ~/experimental/unix_write
$ ls -lt
total 16
-rw-rw-r--  1 cdal  staff  0 Apr 27 08:54 a <-- SHOULD BE 50 BYTES

Można by pomyśleć, że program uruchomi się, przechwyci dowolne dane wyjściowe (ale także zapisze do pliku „a”), a następnie nie zapisuje żadnych danych wyjściowych do ~ root / log. Zamiast tego program nigdy nie jest uruchamiany.

Dlaczego tak jest i w jaki sposób bash wybiera kolejność „kontroli”, które wykonuje przed uruchomieniem programu? Czy przeprowadzane są również inne kontrole?

ps Próbuję ustalić, czy program działający pod cronem faktycznie działał po przekierowaniu do pliku „odmowy uprawnień”.

Tak naprawdę nie jest to kwestia zamawiania czeków, po prostu kolejność, w jakiej powłoka konfiguruje rzeczy. Przekierowania są konfigurowane przed uruchomieniem polecenia; więc w twoim przykładzie powłoka próbuje otworzyć się ~root/logprzed dołączeniem przed próbą wykonania czegokolwiek, co wymaga ./write_file.py. Ponieważ nie można otworzyć pliku dziennika, przekierowanie kończy się niepowodzeniem, a powłoka przestaje w tym momencie przetwarzać wiersz poleceń.

Jednym ze sposobów wykazania tego jest pobranie pliku niewykonywalnego i próba jego uruchomienia:

$ touch demo
$ ./demo
zsh: permission denied: ./demo
$ ./demo > ~root/log
zsh: permission denied: /root/log

To pokazuje, że powłoka nawet nie patrzy, ./demokiedy nie można skonfigurować przekierowania.

Ze strony podręcznika użytkownika bash, sekcja REDIRECTION (podkreślenie przeze mnie):

Przed wykonaniem polecenia jego dane wejściowe i wyjściowe mogą zostać przekierowane przy użyciu specjalnej notacji interpretowanej przez powłokę.

...

Niepowodzenie otwarcia lub utworzenia pliku powoduje niepowodzenie przekierowania.

Więc powłoka próbuje otworzyć plik docelowy stdout, co się nie powiedzie, a polecenie w ogóle nie zostanie wykonane.

Warto zauważyć, że powłoka musi ustanowić przekierowania przed uruchomieniem programu.

Rozważ swój przykład:

./write_file.py >> ~root/log

To, co dzieje się w powłoce, to:

1. My (powłoka) fork(); proces potomny dziedziczy otwarte deskryptory plików od swojego rodzica (powłoki).
2. W procesie potomnym my fopen()(rozwinięcie) „~ root / log” i dup2()to do fd 1 (i close()tymczasowego fd). Jeśli się fopen()nie powiedzie, zadzwoń, exit()aby zgłosić błąd rodzicowi.
3. Wciąż w dziecku mamy exec()„./write_file.py”. W tym procesie nie działa już żaden z naszych kodów (chyba że nie udało się go wykonać, w którym to przypadku exit()zgłosimy błąd do rodzica).
4. Element nadrzędny sprawi, wait()że dziecko zakończy działanie i obsłuży swój kod wyjścia (kopiując go $?przynajmniej do).

Przekierowanie musi więc nastąpić w podrzędnym między fork()i exec(): nie może się zdarzyć wcześniej, fork()ponieważ nie może zmienić standardowej powłoki powłoki, i nie może nastąpić później, exec()ponieważ nazwa pliku i kod wykonywalny powłoki zostały teraz zastąpione przez program Python . Rodzic nie ma dostępu do deskryptorów plików dziecka (a nawet gdyby tak było, nie mógł zagwarantować przekierowania między exec()pierwszym zapisem na standardowe wyjście).

Z przykrością informuję, że jest odwrotnie. Powłoka musi najpierw otworzyć swoje we / wy, a następnie przekazać kontrolę programowi.

tee może okazać się pomocny w tym przypadku: ./write_file.py | tee -a ~root/log > /dev/null