Zasada wywoływania podpowłoki w Bash?

Wydaje mi się, że źle rozumiem zasadę Bash dotyczącą tworzenia podpowłoki. Myślałem, że nawiasy zawsze tworzą podpowłokę, która działa jako własny proces.

Wydaje się jednak, że tak nie jest. W fragmencie kodu A (poniżej) drugie sleeppolecenie nie działa w osobnej powłoce (określonej przez pstreeinny terminal). Jednak we fragmencie kodu B drugie sleeppolecenie działa w osobnej powłoce. Jedyną różnicą między fragmentami jest to, że drugi fragment zawiera dwa polecenia w nawiasach.

Czy ktoś mógłby wyjaśnić tę zasadę podczas tworzenia podpowłoki?

KOD SNIPPET A:

sleep 5
(
sleep 5
)

KOD SNIPPET B:

sleep 5
(
x=1
sleep 5
)

Nawiasy zawsze rozpoczynają podpowłokę. Dzieje się tak, że bash wykrywa, że sleep 5jest to ostatnie polecenie wykonane przez tę podpowłokę, więc wywołuje execzamiast fork+ exec. sleepKomenda zastępuje powłoki w tle w tym samym procesie.

Innymi słowy, podstawowym przypadkiem jest:

1. ( … )utwórz podpowłokę. Oryginalne wywołania procesów forki wait. W podprocesie, który jest podpowłoką:
   1. sleepjest zewnętrznym poleceniem, które wymaga podprocesu podprocesu. Wywołania podpowłoki forki wait. W podprocesie:
      1. Podproces wykonuje polecenie zewnętrzne → exec.
      2. Ostatecznie polecenie kończy się → exit.
   2. wait uzupełnia się w podpowłoce.
2. wait kończy się w oryginalnym procesie.

Optymalizacja to:

1. ( … )utwórz podpowłokę. Oryginalne wywołania procesów forki wait. W podprocesie, który jest podpowłoką, dopóki nie wywoła exec:
   1. sleep jest poleceniem zewnętrznym i jest ostatnią rzeczą, którą ten proces musi zrobić.
   2. Podproces wykonuje polecenie zewnętrzne → exec.
   3. Ostatecznie polecenie kończy się → exit.
2. wait kończy się w oryginalnym procesie.

Po dodaniu czegoś innego po wywołaniu sleepnależy zachować podpowłokę, aby ta optymalizacja nie mogła się zdarzyć.

Kiedy dodasz coś jeszcze przed wywołaniem sleep, można dokonać optymalizacji (i robi to ksh), ale bash tego nie robi (przy tej optymalizacji jest bardzo konserwatywny).

Z Przewodnika programowania zaawansowanego Bash :

„Ogólnie rzecz biorąc, zewnętrzne polecenie w skrypcie odrzuca podproces, podczas gdy wbudowane Bash nie. Z tego powodu wbudowane polecenia wykonują się szybciej i zużywają mniej zasobów systemowych niż ich zewnętrzne odpowiedniki”.

I nieco dalej:

„Lista poleceń osadzona między nawiasami działa jako podpowłoka”.

Przykłady:

[root@talara test]# echo $BASHPID
10792
[root@talara test]# (echo $BASHPID)
4087
[root@talara test]# (echo $BASHPID)
4088
[root@talara test]# (echo $BASHPID)
4089

Przykład użycia kodu OPs (z krótszymi snami, ponieważ jestem niecierpliwy):

echo $BASHPID

sleep 2
(
    echo $BASHPID
    sleep 2
    echo $BASHPID
)

Wyjście:

[root@talara test]# bash sub_bash
6606
6608
6608

Dodatkowa uwaga do odpowiedzi @Gilles.

Jak powiedział Gilles: The parentheses always start a subshell.

Jednak liczby, które ma taka podpowłoka, mogą się powtarzać:

$ (echo "$BASHPID and $$"; sleep 1)
2033 and 31679
$ (echo "$BASHPID and $$"; sleep 1)
2040 and 31679
$ (echo "$BASHPID and $$"; sleep 1)
2047 and 31679

Jak widać, $$ ciągle się powtarza, i to zgodnie z oczekiwaniami, ponieważ (wykonaj to polecenie, aby znaleźć poprawną man bashlinię):

$ LESS=+/'^ *BASHPID' man bash

BASHPID
Rozwija się do identyfikatora procesu bieżącego procesu bash. Różni się to od $$ w pewnych okolicznościach, takich jak podpowłoki, które nie wymagają ponownej inicjalizacji bash.

To znaczy: Jeśli powłoka nie zostanie ponownie zainicjowana, $$ jest taka sama.

Lub z tym:

$ LESS=+/'^ *Special Parameters' man bash

Parametry specjalne
$ Rozwija się do identyfikatora procesu powłoki. W podpowłoce () rozwija się do identyfikatora procesu bieżącej powłoki, a nie podpowłoki.

Jest $$to identyfikator bieżącej powłoki (nie podpowłoki).