>/dev/null 2>&1は「奥が深い症候群」なのか? (追記あり)


ひとつには、前者は「素人くさい、なんかダサイ」、後者は「ハッカーぽい、かっこいい」というのがあると思います。
よくWebで見かけるのが、後者を書こうとして間違えて、「リダイレクトに関する理解が間違っていた」「シェルの仕様を勘違いしていた」といって自分を責めてしまうケースです。
我々エンジニアは真面目な人が多いので、間違えると自分を責めてしまいがちです。
しかし開き直ってみれば、間違いを誘発する記法に問題があるとは言えないでしょうか。

奥が深い症候群

私はこれは「奥が深い症候群」と言えるのではないかと思いました。
バッドノウハウがはびこる大きな理由は、(中略) 別の理由によ るものも根深いと私は考えている。それは、そういった使いにくい ソフトウェアを使いこなす事に対して、「奥が深い」といって喜び を見出す「奥が深い症候群」によるものである。

一般に、マニアという人種は普通の人にとってはどうでもいいよう な知識を熱心に覚えることに喜びを見出すものだが、これが計算機 マニアになると「奥が深い」といってバッドノウハウを喜んで覚え る「奥が深い症候群」になりやすいようである。また、バッドノウ ハウを薀蓄として披露することによって、より一層の喜びを得ると いう心理的な働きも「奥が深い症候群」を進行させる一因となって いるようだ。

本来使いにくいソフトウェアが長年に渡って「奥が深い」定番とし てありがたがられ、そのバッドノウハウの習得にユーザが不毛な時 間を費やすことを強いられるのは、この「奥が深い症候群」に根 深い原因があるのではないかと考えている。

悩ましいのは&

「バッドノウハウ」の一言で片づけてしまえればよかったのですが、悩ましいのが"&"です。
&については、下記のように標準エラー出力にメッセージを出力しようしたら避けて通れません。
echo "error message" 1>&2
Perlのwarnを使えば&を書かずに済むというのを思いつきましたが、これはもっとバッドノウハウ。
perl -e 'warn "error message\n"';
&については、あきらめて覚えるしかなさそうです。

何かよい方法があれば教えてください。

結論(追記)

/dev/nullの代わりに実ファイルを指定した場合、挙動に違いがあることがわかりました。
下記の場合、記法1は正しく動きません。
# 記法1
command 1>a.txt 2>a.txt

# 記法2
command >a.txt 2>&1

記法2には、こう書かざるを得ないちゃんとした理由があり、「奥が深い症候群」ではないことがわかりました。

単なる私の勉強不足でした。
お騒がせして申し訳ありませんでした。

カテゴリ: