2012-04-03 2 views
1

私は小さなスクリプトを書きましたが、何らかの理由でパラメータが渡されたスペースをエスケープして動作させる必要があります。pgrepは予想外のpidを出力します

私はこの問題を抱えている人に関する多くの記事を読んでいますが、通常は$ @を引用しないためですが、すべての変数はスクリプト内で引用され、コマンドラインでも引用されています。また、スクリプトをデバッグモードで実行すると、返された行はコピー貼り付けで正常に実行できますが、スクリプト内から実行すると失敗します。

CODE:

connections() 
{ 
    args="[email protected]" 
    pid="$(pgrep -nf "$args")" 
    echo $pid 
    # code that shows TCP and UDP connections for $pid 
} 
connections "[email protected]" 

例:

bash test.sh "blah blah"

が失敗し、代わりに、現在実行中のシェル

bash test.sh "blah\ blah"

成功のPIDを返すとのPIDを返します。 procあなたはpgrepで検索しています

+0

これはあなたの問題ではありませんが、ここでは "$ @"の使い方をよく理解していません。 'connections'は明らかに1つの引数しか取らないように設計されているようで、複数の引数を受け取った場合、誤動作します(' pgrep -nf'にこれらの引数をすべて渡して、最初の引数がコマンド行およびすべての後続の引数はプロセス名とのみ一致します)。だから代わりに '' $ 1 ''だけを使うのではないのですか?あるいは、複数の引数がある場合は、エラーや警告を表示する方が良いでしょうか? – ruakh

+0

私はすでにそれを試みて、同じ問題を抱えていました。 $ @のすべてのインスタンスを$ 1に置き換えた場合、同じ問題が発生します(スペースをエスケープするとスペースが有効になり、エスケープしないと現在のシェルのpidが取得されます) –

+0

はい:私が言ったように、問題ではありません。しかし、私はまだあなたがそれを悪用しようとしている理由は見ていません。 – ruakh

答えて

1

問題は"[email protected]"とは関係ありません。

あなたはpgrep-lオプションを追加する場合は、それが現在のプロセスにマッチだ、なぜ、あなたはを見ることができます。

実行中のスクリプトには、独自の引数で検索しようとしているものが含まれています

それはこれをやって、そしてgrepを見るようなものだ:

$ ps -U $USER -o pid,cmd | grep gnome-terminal 
12410 grep gnome-terminal 
26622 gnome-terminal --geometry=180x65+135+0 

バックスラッシュが違いを作る理由は?バックスラッシュ+スペースは単にスペースを意味すると考えています。あなたのスクリプトは見つからない。blah\ blahで、blah blahではないからだ。

関連する問題