Tworzenie podpowłoki za pomocą nawiasów klamrowych

Zgodnie z tym , umieszczenie listy poleceń między nawiasami klamrowymi powoduje, że lista jest wykonywana w bieżącym kontekście powłoki. Nie jest tworzona podpowłoka .

Za pomocą, psaby zobaczyć to w akcji

Jest to hierarchia procesów dla potoku procesu wykonywanego bezpośrednio w wierszu poleceń. 4398 to PID dla powłoki logowania:

sleep 2 | ps -H;
  PID TTY          TIME CMD
   4398 pts/23   00:00:00 bash
   29696 pts/23   00:00:00   sleep
   29697 pts/23   00:00:00   ps

Teraz postępuje zgodnie z hierarchią procesu dla potoku procesu między nawiasami klamrowymi wykonywanymi bezpośrednio w wierszu poleceń. 4398 to PID dla powłoki logowania. Jest to podobne do powyższej hierarchii udowadniającej, że wszystko jest wykonywane w bieżącym kontekście powłoki :

{ sleep 2 | ps -H; }
   PID TTY          TIME CMD
    4398 pts/23   00:00:00 bash
    29588 pts/23   00:00:00   sleep
    29589 pts/23   00:00:00   ps

Jest to hierarchia procesów, sleepw której potok jest umieszczony wewnątrz nawiasów klamrowych (czyli w sumie dwa poziomy nawiasów klamrowych)

{ { sleep 2; } | ps -H; }
  PID TTY          TIME CMD
   4398 pts/23   00:00:00 bash
   29869 pts/23   00:00:00   bash
   29871 pts/23   00:00:00     sleep
   29870 pts/23   00:00:00   ps

Dlaczego bashtrzeba utworzyć podpowłokę, aby działała sleepw trzecim przypadku, gdy dokumentacja stwierdza, że ​​polecenia między nawiasami klamrowymi są wykonywane w bieżącym kontekście powłoki?

W potoku wszystkie polecenia są uruchamiane jednocześnie (z ich stdout / stdin połączonymi rurami), a więc w różnych procesach.

W

cmd1 | cmd2 | cmd3

Wszystkie trzy polecenia działają w różnych procesach, więc co najmniej dwa z nich muszą działać w procesie potomnym. Niektóre powłoki uruchamiają jedną z nich w bieżącym procesie powłoki (jeśli są wbudowane readlub jeśli potok jest ostatnim poleceniem skryptu), ale bashwszystkie działają w osobnym procesie (z wyjątkiem lastpipeopcji w najnowszych bashwersjach i pod pewnymi warunkami ).

{...}grupuje polecenia. Jeśli ta grupa jest częścią potoku, musi działać w osobnym procesie, podobnie jak proste polecenie.

W:

{ a; b "$?"; } | c

Potrzebujemy powłoki, aby ocenić, że a; b "$?"jest to osobny proces, dlatego potrzebujemy podpowłoki. Powłoka mogłaby zoptymalizować nie buruchamiając forka, ponieważ jest to ostatnie polecenie, które można uruchomić w tej grupie. Niektóre pociski to robią, ale najwyraźniej nie bash.

Zagnieżdżanie nawiasów klamrowych wydaje się oznaczać, że tworzysz dodatkowy poziom zakresu, który wymaga wywołania nowej podpowłoki. Możesz zobaczyć ten efekt z drugą kopią Bash w twoich ps -Hwynikach.

Tylko procesy określone na pierwszym poziomie nawiasów klamrowych są uruchamiane w zakresie oryginalnej powłoki Bash. Wszelkie zagnieżdżone nawiasy klamrowe będą działały we własnej skorupie Bash o określonym zasięgu.

Przykład

$ { { { sleep 20; } | sleep 20; } | ps -H; }
  PID TTY          TIME CMD
29190 pts/1    00:00:00 bash
 5012 pts/1    00:00:00   bash
 5014 pts/1    00:00:00     bash
 5016 pts/1    00:00:00       sleep
 5015 pts/1    00:00:00     sleep
 5013 pts/1    00:00:00   ps

Po | ps -Husunięciu mieszanki, abyśmy mogli zobaczyć zagnieżdżone nawiasy klamrowe, możemy uruchomić ps auxf | lessinną powłokę.

saml     29190  0.0  0.0 117056  3004 pts/1    Ss   13:39   0:00  \_ bash
saml      5191  0.0  0.0 117056  2336 pts/1    S+   14:42   0:00  |   \_ bash
saml      5193  0.0  0.0 107892   512 pts/1    S+   14:42   0:00  |   |   \_ sleep 20
saml      5192  0.0  0.0 107892   508 pts/1    S+   14:42   0:00  |   \_ sleep 20
saml      5068  0.2  0.0 116824  3416 pts/6    Ss   14:42   0:00  \_ bash
saml      5195  0.0  0.0 115020  1272 pts/6    R+   14:42   0:00      \_ ps auxf
saml      5196  0.0  0.0 110244   880 pts/6    S+   14:42   0:00      \_ less

Ale czekaj, jest więcej!

Jeśli jednak wyjmiesz rury i użyjesz tej formy polecenia, zobaczymy, czego się właściwie spodziewałbyś:

$ { { { sleep 10; } ; { sleep 10; } ; sleep 10; } } | watch "ps -H"

Teraz w wynikowym oknie zegarka otrzymujemy aktualizację co 2 sekundy tego, co się dzieje:

Oto pierwszy sleep 10:

  PID TTY          TIME CMD
29190 pts/1    00:00:00 bash
 5676 pts/1    00:00:00   bash
 5678 pts/1    00:00:00     sleep
 5677 pts/1    00:00:00   watch
 5681 pts/1    00:00:00     watch
 5682 pts/1    00:00:00       ps

Oto drugi sleep 10:

  PID TTY          TIME CMD
29190 pts/1    00:00:00 bash
 5676 pts/1    00:00:00   bash
 5691 pts/1    00:00:00     sleep
 5677 pts/1    00:00:00   watch
 5694 pts/1    00:00:00     watch
 5695 pts/1    00:00:00       ps

Oto trzeci sleep 10:

  PID TTY          TIME CMD
29190 pts/1    00:00:00 bash
 5676 pts/1    00:00:00   bash
 5704 pts/1    00:00:00     sleep
 5677 pts/1    00:00:00   watch
 5710 pts/1    00:00:00     watch
 5711 pts/1    00:00:00       ps

Zauważ, że wszystkie trzy sny, chociaż wywoływane na różnych poziomach zagnieżdżenia nawiasów klamrowych, faktycznie pozostają w obrębie PID 5676 Bash. Uważam więc, że Twój problem został spowodowany przez samego użytkownika | ps -H.

Wnioski

Użycie | ps -H(tj. Potoku) powoduje dodatkową podpowłokę, więc nie używaj tej metody, gdy próbujesz przesłuchać, co się dzieje.

Zamieszczę wyniki moich testów, co doprowadziło mnie do wniosku, że bash tworzy podpowłokę dla polecenia grupy, i tylko wtedy, gdy jest częścią potoku, to jest tak, jakby ktoś wywołał jakąś funkcję, która byłaby również nazwana w podpowłoce.

$ { A=1; { A=2; sleep 2; } ; echo $A; }
2

$ { A=1; { A=2; sleep 2; } | sleep 1; echo $A; }
1