Polecenie ps i grep

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,

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