$(pgrep -f) スクリプト内の動作は shebang によって変わります。

$(pgrep -f) スクリプト内の動作は shebang によって変わります。

次のスクリプトを実行するとき:

#!/bin/bash
$(pgrep -u ubuntu -f ${1} > /dev/null)
echo "CURRENT_STATUS="${?}

そして:

./my_script.sh top

top実行されない場合は、次を返します。

CURRENT_STATUS=0

1終了状態が予想されたため、これは奇妙ですpgrep。スクリプトからshebangを削除すると、期待どおりに動作します。

ここで何が起こっているのかを理解するのに役立つ人はいますか?

これはUbuntu 22.4.1システムにあります。また、これは$(...)結果を変更しません。

私はこれがpgrepそれ自体で一致するようだと思った。したがって、どのプロセス名を入力しても結果はゼロになります。

答え1

hashbangを使用して、カーネルは名前付きインタプリタを実行してスクリプトファイル名とユーザーが提供した引数(コマンドライン)を渡し、/bin/bash ./my_script.sh topeg in the process listとして表示され、ps同様にpgrep検索します。top最終的にキーワードと一致します。

hashbang がないと、カーネルレベルのシステムコールが失敗し、Bash は内部的にスクリプト自体を実行し、パラメータはプロセスリストに表示されません。 (シェルはこれを何らかの形で行います。IIRCは、実行不可能なファイルが可能であればシェルを介して実行する必要があるというPOSIX要件です。)

次の2つのテストを使用する方が簡単です。

bash$ cat wait.sh
#!/bin/bash
sleep 50

bash$ cat wait2.sh
sleep 50

bash$ ./wait.sh & ./wait2.sh & ps uax |grep wait
ilkkachu  9029  0.0  0.0  15368  3060 pts/21   S    20:01   0:00 /bin/bash ./wait.sh
ilkkachu  9032  0.0  0.0  16964   968 pts/21   S+   20:01   0:00 grep wait

ハッシュバンがない人は現れません。

pgrep私はそれ自体が見つからないほどスマートで、代わりにスクリプトを見つけるのに役立つと思います。このようなパターンは利用可能で'[t]op'一致topしますが、それ自体は一致しません。これにより./my_script.sh '[t]op'差がなくなります。

しかし、そこにあるコマンドの置き換えは役に立たないので、ちょうど捨ててくださいpgrep

関連情報