シェルがリダイレクトを解析する方法の奇妙な動作を理解するのに役立つ人はいますか？
$ cat > test.txt
Line 1
Line 2
$ ls -i dummy.txt dummy2.txt
ls: dummy.txt: No such file or directory
ls: dummy2.txt: No such file or directory
$
$ cat test.txt > dummy.txt > dummy2.txt
$ cat dummy2.txt
Line 1
Line 2
$ cat dummy.txt
$
興味深い！私は出力cat test.txtにリダイレクトされ、次のシェルは、dummy.txt入力dummy.txtをdummy2.txt。しかし、どういうわけかシェルはそれを別の方法で解析します...
test.txtそれでは、入力へdummy2.txtの内容をどのように完全にバイパスできますかdummy.txt？
メモ: bashとkshで同じ結果..
ベストアンサー1
シェルがリダイレクトされないことを知ることが重要です出力しかし、ファイル記述子。 POSIX準拠のオペレーティングシステムのすべてのプロセスには、STDIN、STDOUT、およびSTDERRの3つのI / Oストリームがあります。リダイレクトは、>STDOUTストリームのファイル記述子をリダイレクトします。したがって、この行を解析するときにシェルが表示する内容は次のとおりです。
cat test.txt- いいね、プログラムを実行しcatてパラメータを入力します。test.txt> dummy.txt- ああ、今プロセスのSTDOUT記述子を取得し、cat"dummy.txt"というファイルに接続します。以前に何もなかったかどうかに関係なく、ファイルを作成してゼロに切り捨てます。> dummy2.txt- ああ、今プロセスのSTDOUT記述子cat（以前は「dummy.txt」に接続していた）をインポートし、別の新しいファイルに接続します。代わりにリダイレクトしているため、同時に両方を実行することはできません。繰り返すファイル記述子。
そのため、このコマンドは次のようになります。
find / 2>&1 >/dev/null
STDOUTではエラー出力が発生し、一般（STDOUT）出力は発生しませんが、次のようになります。
find / >/dev/null 2>&1
結果はまったく出力されません。最初のケースでは、STDERRをSTDOUTのコピー（dup）に入れ、古いSTDOUTをごみ箱に入れます。 2番目では、まずSTDOUTをゴミ箱に入れてからコピーして（まだ指しています/dev/null）、STDERRもそこに入れます。