次のスクリプトを実行するとき：
#!/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。