注:この問題は、「プロセスの交換」の非同期処理が原因で発生します。スクリプトの応答は欺瞞的なので、多くの時間の損失が発生します。以前の関連投稿はここにあります。猫は交換の過程で停止します。何を待っていますか?
Bash 4.4.19(1) - リリース
このコードは、次の理由で使用されます。パイプは使用できません。。
func() {
in=$(cat)
echo "'this is it: $in'"
}
echo "a string" > >(func)
残念ながら、このプロセスの置き換えは私の文字列でプロンプトを印刷します。
user@srv:~$ ./test.sh
user@srv:~$ 'this is it: a string'
これは私の使用には望ましくありません!最小限に言えば! ! !
理想的なのは、次のような通常の動作です。
user@srv:~$ ./test.sh
'this is it: a string'
プロセス置換がシェルプロンプトを印刷しないように強制できますか?
注:パイプは利用できません...他の問題が発生します。 これによって発生する問題は次のとおりです。 コマンド出力をファイル(1行)に送信する前に処理できますか?
答え1
これは、スクリプトがプロセスで置き換えられたサブプロセスの前に返されるために発生します>(...)
。非同期的(つまり、バックグラウンドで)スクリプトを呼び出したシェルがプロンプトを印刷した後にのみ内容を印刷します。
回避策は次のとおりですwait
。残念ながら、サブシェルなどで実行されるプロセスはタスクの一部として管理されず、タスクbash
テーブルには表示されないため、以下を使用する必要がありますpgrep -P
(親で検索)。
func() {
in=$(cat)
sleep .2
echo "'this is it: $in'"
}
echo "a string" > >(func)
wait $(pgrep -P $$)
sleep .2
pgrep
(症状が誤って消えるのを防ぐために追加しました。実行に時間がかかる場合は、wait
非同期プロセスが終了するのに十分な場合があります。)
内部で実行されるプロセスが基本スクリプトのサブプロセスであるという仮定は、組み込み> >(...)
関数、関数、およびグループコマンドと共に使用された場合にのみ適用されます。ここ詳細については。