PSコマンドとGREP

ps -ef | grep $$がgrepコマンドをプロセスリストに表示するのはなぜですか？が彼の仕事を終えたgrep後に処刑されていませんpsか？

linux shell

— マリガン
ソース

それはパイプラインと呼ばれています...

— Ipor Sircer

最初のコマンドが完了するまで待機した場合、パイプラインは、自力で停止しないコマンドをどのように処理しますtail -f filename | grep patternか？

— Barmar 16

クロスサイト重複でパイプされたコマンドは、どのような順序を実行するのですか？

— スコット

コマンドをパイプ処理すると、すべてのプロセスが同時に開始され、I / Oがプロセスに入る/プロセスが終了するまでスリープ（ブロック）するだけです。シェルは、出力をバッファリングせず、1つのプロセスが完了するまでそれを保持せず、それを別のプロセスに転送します。

例えば：

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

結果：

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

/ procツリーでgrepプロセスの状態を確認できます。

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

また、両方のgrepsが同じパイプライン（id 57573438）に1接続され、最初のプロセスのSTDOUT（）が02番目のプロセスのSTDIN（）に接続されていることもわかります。

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
ソース

彼らは寝た後、sleepコマンドに入れていることを言っているが、それは睡眠が、それはむしろシェルによって行われている何かよりも、あなたの睡眠のコマンドだと言うとき、それは、cosを」複雑な例のビットそれだ

— barlop

少しだけ遅延を導入するために、sleepコマンドをそこに配置するだけで、システムを見回すことができます。sleepコマンドは、grepが入力を受信しないことを除いて、その背後のgrepに影響を与えません。それはあなたを幸せにする場合は、タールと同じことを行うことができます$ tar -zcvf test.tgz /lib/ | grep foo | grep barし、その後grepを確認します$ cat status Name: grep State: S (sleeping)

— mtak

すでに編集しているので、より明確です。

— mtak 2016