「合流」と考えてしまっていることだ。「2番を1番に合流させているんだから、1番をリダイレクトすれば両者ともに出力先が変わる」と考えてしまっていることだ。実際のリダイレクトはそういった処理はしていない。実際のリダイレクトの処理は、コマンドラインの左から右へ、ファイルディスクリプタをオープン/クローズしながら進められる。以下のサイトの説明を読んだ方が早い。シェルのファイルディスクリプタ操作http://home.catv.ne.jp/pp/ginoue/memo/sh-fd.htmlまずは正しい例。2>&1また実装例から示します。2>&1」が左から処理されていく過程を追います。「>outfile.txt」は上と同じで、ファイルを指すfdが作られた後、1番が一旦クローズされてfdの複製として再生され、ついでにfdがクローズされます。「2>&1」は、2番が一旦クローズされて1番の複製として再生されます。1);一旦1番をクローズ。1番がfdの複製として再生される。2);一旦2番をクローズ。2番が1番の複製として再生される。[file]結局、1番も2番もファイル(outfile.txt)を指すことになります。lsの標準出力も標準エラー出力もファイルに出力されます。次に、私が間違った例。>outfile.txtいつものように実装例から。1);close(fd);「2>&1」も「>outfile.txt」も、上で説明したとおりの動作をします。左から処理が進むので、処理の順番が異なるだけですが、最終形態も異なります。2);一旦2番をクローズ。2番が1番の複製として再生される(結局、画面のまま)。1);一旦1番をクローズ。1番がfdの複製として再生される。[file])結局、1番がファイルを指して、2番は画面のままです。合流とかそういうものではなく、毎回毎回ファイルディスクリプタのオープンとクローズが行われていることがわかる。すごい間違い私がやった失敗をもう一つ。&2>1標準エラー出力を1番のファイルディスクリプタに向けようとしたのだが、この記述だとやりたかったこととはまったく違う結果になる。指定されているためコマンドはバックグラウンドで実行される。いうファイルに向けられる。普通ならば「バックグラウンド実行されたよ」という旨のメッセージが表示されるため、すぐに間違いに気づく。書いていたため、発見が遅れてしまった。いうファイルができており、そのときになって初めて気づいたのだった。manipulationhttp://home.catv.ne.jp/pp/ginoue/memo/sh-fd.htmlリダイレクトやパイプがどんな仕組みで成り立っているのかを図解つきで解説。普段は抽象化された入出力ライブラリに頼りっきりでファイルディスクリプタをあまり意識していないが、非常にわかりやすかった。