bashスクリプトでstderrメッセージを抑制します

次の（少し馬鹿げた）スクリプト名 'test1.sh'を検討してください。

#/bin/bash
#
sleep 10 &
echo sleep pid = $!
pkill sleep

実行すると、エコーの出力だけでなく、stderrでのスリープの終了に関するbashのレポートも取得されます。

$ ./test1.sh
sleep pid = 3551
./test1.sh: line 5:  3551 Terminated              sleep 10

この場合、stderrへの印刷を抑制したいと思います。次のように、コマンドラインで実行できることを知っています。

$ ./test1.sh 2> /dev/null

...しかし、スクリプト内からそれを抑制する方法はありますか？（私はそれを2番目のスクリプトでラップしてラッパーにリダイレクトさせることができることを知っていますが、もっと簡単なものが必要です...）

bash shell-script stderr

— fearless_fool
ソース

pkill sleepの後にリダイレクト2> / dev / nullを追加しようとしましたか？

— ラーウル

@rahul：はい、そうです-pkillはメッセージを生成していません、bashは生成しています。

— fearless_fool

pkillの代わりにkillを使用し、stderrを取得しません。奇妙な

— .-ラール

@rahul：それは組み込みのものか非組み込みのものか？あなたもpkillで試しましたか？

— fearless_fool

はい、そうです。pkillでも同じエラーが発生しますが、killでは発生しません。killを使用している間、proc名の代わりにpidを使用しました。

— ラーウル

回答:

あなたが正しい; pkillはメッセージを生成していませんが、bashは生成しています。あなたはそれを提案する

$ ./test1.sh 2> /dev/null

可能な解決策です。UVVが指摘しているように、スクリプト内からの同等のアクションは

exec 2> /dev/null

これにより、スクリプトのstderrは、/dev/null 元に戻されるまでこのステートメントからリダイレクトされます。それを元に戻す不器用な方法には、

exec 2> /dev/tty

stderrを端末にリダイレクトします。これはおそらく（必ずしもではありませんが）元の場所です。

または

exec 2>&1

これは、stderrをstdoutと同じ値に設定し、おそらく間違っている可能性があります。

より信頼できる方法は

exec 3>＆2
exec 2> / dev / null
（stderrを表示したくない場所で作業を行ってください。） 
exec 2>＆3

これにより、元のstderrがファイル記述子3に保存され、後で復元されます。

プロセスの終了のアナウンスだけを抑制する他の方法には、

(sleep 10 & pkill sleep) 2> /dev/null

そして

{ sleep 10 & pkill sleep;} 2> /dev/null

グループ化されたコマンドに対してのみ標準エラーを変更します。

— スコット
ソース

これは非常に優れた詳細な回答です。ありがとうございます！

— キーナンローレンス

新しいファイル記述子の保存stdinと保存stderr、元の記述子の送信/dev/nullと復元に関連する危険性はありますか？

— アレクセイマグラ

さて、ファイル記述子3（または4）に（知らないうちに）書き込むプログラムを実行した場合、通常の状況ではその操作は失敗すると思います。しかし、プログラムは、失敗を無視し、報告せずに続行するように作成できます。それからあなたは決して知りません。ただし、ファイル記述子1（または2）がファイル記述子3（または4）に「パーク」されている場合、そのプログラムは突然スクリプトのstdoutまたはstderrに書き込みます。しかし、それは非常に不自然な例であり、依然として最小限の危険です。あなたは何かを考えていましたか？

— スコット

FWIW、私はすなわち、スコットのグループ化されたコマンドアプローチを好む{ sleep 10 & pkill sleep;} 2> /dev/null

— fearless_fool

これによると、次のようなことができます：

#!/bin/bash
exec 2>/dev/null
ls -al test

— UVV
ソース