Polecenie ps i grep

8

Dlaczego ps -ef | grep $$pokazuje greppolecenie na liście procesów? Czy grepegzekucja nie jest wykonywana po pszakończeniu pracy?

linux shell Mulligan
źródło
To się nazywa rurociąg ...
Ipor Sircer
Gdyby czekało do zakończenia pierwszego polecenia, jak potoki działałyby z poleceniami, które same się nie zatrzymują tail -f filename | grep pattern?
Barmar
Duplikat między witrynami W jakiej kolejności są uruchamiane polecenia potokowe?
Scott,

Odpowiedzi:

11

Podczas przesyłania komend wszystkie procesy są uruchamiane w tym samym czasie, a one po prostu śpią (blokują), aż wejdzie / wyjdzie z nich. Powłoka nie buforuje wyniku i nie zatrzymuje go, dopóki jeden proces nie zostanie zakończony, a następnie nie zostanie przeniesiony do innego procesu.

Na przykład:

mtak@rubiks:~$ tar -zcvf test.tgz /lib/ | grep bla | grep foo | grep bar

Prowadzi do:

mtak 28813 28799  0 12:35 pts/17   00:00:00 tar -zcvf test.tgz /lib/
mtak 28814 28799  0 12:35 pts/17   00:00:00 grep --color=auto bla
mtak 28815 28799  0 12:35 pts/17   00:00:00 grep --color=auto foo
mtak 28816 28799  0 12:35 pts/17   00:00:00 grep --color=auto bar

Możesz zobaczyć stan procesu grep w drzewie / proc:

mtak@rubiks:~$ grep State /proc/28814/status
State:  S (sleeping)

Możesz także zobaczyć, że oba greps są podłączone do tego samego potoku (id 57573438) i że STDOUT ( 1) pierwszego procesu jest podłączony do STDIN ( 0) drugiego procesu.

root@rubiks:~# ls -l /proc/28815/fd
total 0
lr-x------ 1 mtak mtak 64 dec  1 12:35 0 -> pipe:[57573437]
l-wx------ 1 mtak mtak 64 dec  1 12:35 1 -> pipe:[57573438]
lrwx------ 1 mtak mtak 64 dec  1 12:35 2 -> /dev/pts/17

root@rubiks:~# ls -l /proc/28816/fd
total 0
lr-x------ 1 mtak mtak 64 dec  1 12:35 0 -> pipe:[57573438]
lrwx------ 1 mtak mtak 64 dec  1 12:35 1 -> /dev/pts/17
lrwx------ 1 mtak mtak 64 dec  1 12:35 2 -> /dev/pts/17
mtak
źródło
jest to jednak trochę skomplikowany przykład, aby powiedzieć, że śpią, a następnie wprowadzić komendę snu, bo wtedy, gdy mówi snu, jest to twoja komenda snu, a nie coś, co wykonuje skorupa
barlop
Po prostu wstawiłem tam polecenie uśpienia, aby wprowadzić pewne opóźnienie, aby móc rozejrzeć się po systemie. Polecenie uśpienia nie wpływa na grep za nim, z wyjątkiem tego, że grep nie otrzymuje żadnych danych wejściowych. Jeśli cię to uszczęśliwia, możesz zrobić to samo z tar: $ tar -zcvf test.tgz /lib/ | grep foo | grep bara następnie sprawdź grep:$ cat status Name: grep State: S (sleeping)
mtak
Już go edytowałem, więc jest bardziej przejrzysty.
mtak