>/dev/null 2>&1は「奥が深い症候群」なのか？ (追記あり)
ひとつには、前者は「素人くさい、なんかダサイ」、後者は「ハッカーぽい、かっこいい」というのがあると思います。
よくWebで見かけるのが、後者を書こうとして間違えて、「リダイレクトに関する理解が間違っていた」「シェルの仕様を勘違いしていた」といって自分を責めてしまうケースです。
我々エンジニアは真面目な人が多いので、間違えると自分を責めてしまいがちです。
しかし開き直ってみれば、間違いを誘発する記法に問題があるとは言えないでしょうか。
奥が深い症候群
私はこれは「奥が深い症候群」と言えるのではないかと思いました。バッドノウハウがはびこる大きな理由は、(中略) 別の理由によ るものも根深いと私は考えている。それは、そういった使いにくい ソフトウェアを使いこなす事に対して、「奥が深い」といって喜び を見出す「奥が深い症候群」によるものである。
一般に、マニアという人種は普通の人にとってはどうでもいいよう な知識を熱心に覚えることに喜びを見出すものだが、これが計算機 マニアになると「奥が深い」といってバッドノウハウを喜んで覚え る「奥が深い症候群」になりやすいようである。また、バッドノウ ハウを薀蓄として披露することによって、より一層の喜びを得ると いう心理的な働きも「奥が深い症候群」を進行させる一因となって いるようだ。
本来使いにくいソフトウェアが長年に渡って「奥が深い」定番とし てありがたがられ、そのバッドノウハウの習得にユーザが不毛な時 間を費やすことを強いられるのは、この「奥が深い症候群」に根 深い原因があるのではないかと考えている。
悩ましいのは&
「バッドノウハウ」の一言で片づけてしまえればよかったのですが、悩ましいのが"&"です。&については、下記のように標準エラー出力にメッセージを出力しようしたら避けて通れません。
echo "error message" 1>&2perl -e 'warn "error message\n"';何かよい方法があれば教えてください。
結論（追記）
/dev/nullの代わりに実ファイルを指定した場合、挙動に違いがあることがわかりました。下記の場合、記法１は正しく動きません。
# 記法１
command 1>a.txt 2>a.txt
# 記法２
command >a.txt 2>&1記法２には、こう書かざるを得ないちゃんとした理由があり、「奥が深い症候群」ではないことがわかりました。
単なる私の勉強不足でした。
お騒がせして申し訳ありませんでした。