対話型BASHスクリプトを実行しているユーザーからすべてのstderrを非表示にしますが、ログファイルにエラーを残します。ただし、単純なstderrリダイレクトは、予期せず次に移動する必要があるBASH出力の一部を隠します。標準出力代わりに。両方のシステムでこれを試しましたが、同じ結果が得られました。GNU bash、バージョン 4.1.2(1)-リリース(x86_64-redhat-linux-gnu)もう一つはMacOS Xにあります)。
私はこれがexec
シェルの変更によって引き起こされる可能性があると常に疑っていましたが...他の組み込み(times
)は期待どおりに機能し、次のように出力します。標準出力!
一例:
#!/bin/bash
exec 2>>file_log
echo This will be printed to stdout, as expected
ls ThereIsNoSuchFileOnEarth # this will go to “file_log”, as expected
read –p 'User would never see this prompt and it would go to file_log. Totally unexpected.' –r -e test
species=”Daleks Raxacoricofallapatorians Judoon”
select enemy in $species;
do
# …code omitted as the user would never see the list. It would go into file_log again!
done
答え1
read
とさんのヒントselect
すべき実際のプロンプトではなく、ユーザーとの対話のプロンプトである可能性があるため、標準エラーに進んでください。出力。これにより、実際の出力を「汚染」することなく、ユーザーから情報を実行し、引き続き使用してtool.sh > tool.out
収集することができます。read
select
標準出力は1つのプログラムの一般的な出力であり、理想的には手間や複雑さなしに他のプログラムの標準入力にパイプすることができます。
curl
たとえば、ダウンロードの進行状況がstdoutではなくstderrに表示される理由ですcurl http://www.example.com/path/to/file > file
。コンテンツを表示するだけで、リダイレクトはstderrを使用して表示されます。file
file
答え2
シェル全体をリダイレクトする stderr を使用すると、exec
シェル全体に影響します。
exec
リダイレクトを使用してstderr全体をリダイレクトできないか、次のように呼び出す必要があります。
read .... 2> /dev/tty
関連する組み込み関数が stderr に対して読み取れる出力を生成するようにします。