Jak bash traktuje „>> ()”

Podczas eksperymentów z przekierowaniem wyjścia i podstawieniem procesu natknąłem się na następującą komendę i jej wynik:

    me @ elem: ~ $ echo foo>> (cat); pasek echa
    bar
    me @ elem: ~ $ foo

(Tak, ta pusta nowa linia na końcu jest celowa).

Więc uderz w pasek echa, wypisuje mój zwykły monit, echo foo, echo jest nową linią i pozostawia tam mój kursor. Jeśli ponownie wcisnę Enter, wydrukuje mój monit w nowym wierszu i pozostawi kursor za nim (zgodnie z oczekiwaniami, gdy ktoś uderzy Enter w pustym wierszu poleceń).

Spodziewałem się, że napisze foo do deskryptora pliku, cat czyta foo i echo, pasek drugiego echa, a następnie wraca do wiersza poleceń. Ale oczywiście tak nie jest.

Czy ktoś mógłby wyjaśnić, co się dzieje?

Może być foowyświetlany przed bar, po bar, a nawet po monicie, w zależności od czasu. Dodaj małe opóźnienie, aby uzyskać spójny czas:

$ echo foo > >(sleep 1; cat); echo bar; sleep 2 
bar
foo
$

barpojawia się natychmiast, potem foopo jednej sekundzie, a następnie kolejny monit po kolejnej sekundzie.

Dzieje się tak, że bash wykonuje podstawienia procesów w tle.

1. Główny proces bash uruchamia podpowłokę do wykonania sleep 1; cati ustawia do niej potok.
2. Wykonywany jest główny proces bash echo foo. Ponieważ nie zapełnia to bufora potoku, echopolecenie kończy się bez blokowania.
3. Wykonywany jest główny proces bash echo bar.
4. Główny proces bash uruchamia polecenie sleep 2.
5. Tymczasem podpowłoka uruchamia polecenie sleep 1.
6. Po około 1 sekundzie sleep 1wraca do podprocesu. Podproces przechodzi do wykonania cat.
7. cat kopiuje dane wejściowe na dane wyjściowe (wyświetlane na ekranie) i zwraca.
8. Podkładka zakończyła pracę, wychodzi.
9. Po kolejnej sekundzie sleep 2wraca. Proces powłoki głównej kończy się i pojawia się następny monit.

Nie potrzebujesz substytucji procesu, aby uzyskać ten efekt. Spróbuj tego:

( echo foo | cat & )

Otrzymasz ten sam wynik (bez bar; zostawię to jako ćwiczenie) i z tego samego powodu. W obu przypadkach catjest uruchamiany jako zadanie w tle. W mojej linii tutaj jest to jednoznaczne. W przypadku podstawienia procesu jest on również jawny - jest to osobny proces dołączony do deskryptora pliku nazwy - ale być może nie jest tak oczywisty.

Proces potomny niekoniecznie kończy się przed bashwydrukowaniem następnego monitu. A ponieważ jego dane wyjściowe są buforowane, nic nie wysyła, dopóki się nie zakończy. W tym momencie bash właśnie drukował $na stderr, a teraz proces w tle kończy się po wydrukowaniu fooi nowej linii.