リダイレクトの順序

コンピューターがこのコマンドをどのように読み取るかはよくわかりません。

cat file1 file2 1> file.txt 2>&1

理解できれば、2>&1単に標準エラーを標準出力にリダイレクトします。

そのロジックにより、コマンドは次のように読み取られます。

1. ファイルfile1とfile2。

2. stdoutこの操作からに送信しfile.txtます。

3. に送信stderrしstdoutます。

4. 終わり？

コンピューターが何をしているのかわかりません。私の論理では、コマンドは

cat file1 file2 2>&1 > file.txt

しかし、これは正しくありません。

割り当ての使用は簡単に考えられます。

• > のようなものです =
• & のようなものです $

で始まる

1 = /dev/tty
2 = /dev/tty

その後、最初の例は1> file.txt 2>&1、

1 = file.txt
2 = $1           # and currently $1 = file.txt

あなたを残す

1 = file.txt
2 = file.txt

あなたが他の方法でそれをした場合、再びあなたは

1 = /dev/tty
2 = /dev/tty

その後2>&1 > file.txtん

2 = $1           # and currently $1 = /dev/tty
1 = file.txt

最終結果は

1 = file.txt
2 = /dev/tty

そして、あなたはリダイレクトしているだけで、リダイレクトstdoutしていませんstderr。

リダイレクトの順序は重要であり、左から右に読む必要があります。

例えば： command 2>&1 >somefile意味：

1. stderr（つまり2）現在にリダイレクトします宛先stdout（この時点で端末）に。
2. 次にstdout、に移動しますsomefileます。

この場合、 stderrターミナルにstdout移動し、ファイルに移動しますが、これはおそらく望んでいないことです。

一方、 command >somefile 2>&1ことを意味します。

1. リダイレクト stdoutへsomefile
2. 次にstderr、stdout（と同じ宛先にリダイレクトしますsomefile）ます。

この最後のケースでは、stderrとの両方にstdout進みsomefileます。これはおそらくあなたが望むものです。

cat file1 file2 1> file.txt 2>&1

>& 実際には複製を意味し、dupシステムコールを使用して、新しいファイル記述子を既に開いているファイルにマッピングします。

そのため、（実際にはbash）最初に新しいstdoutを開き、「stderrを現在設定されているstdoutにリダイレクトする」必要があります。