>＆-は> / dev / nullよりも効率的ですか？

昨日、私はこのSOコメントを読みました。このコメントでは、シェル内で（少なくともbash）は>&-「と同じ結果になります」と述べてい>/dev/nullます。

そのコメントは、実際にはその情報源としてABSガイドを参照しています。しかし、そのソースは、>&-構文が「ファイル記述子を閉じる」と述べています。

ファイル記述子を閉じてヌルデバイスにリダイレクトするという2つのアクションが完全に同等であるかどうかは明確ではありません。だから私の質問は：彼らですか？

表面的には、記述子を閉じることはドアを閉じることに似ていますが、ヌルデバイスにリダイレクトすることはリンボへのドアを開くことです！閉じたドアが見えても、そこから何も捨てようとしないので、この2つはまったく同じようには見えませんが、開いたドアがあれば、できると思います。

言い換えれば、ファイルのすべてのバイトを実際に処理し、それを忘れたファイルに書き込むことを>/dev/null意味するのかどうか、私はいつも疑問に思っていました。一方、シェルが閉じられたファイル記述子に遭遇した場合、私は考える傾向がある（ただし、わからない）疑問が残るかどうかかかわらず、それは単に、何も書かないということはまだだろう読んですべてのバイトを。cat mybigfile >/dev/null/dev/nullcat

このコメントは「同じである必要が>&-あります>/dev/null」と言っていますが、それは私にとってそれほど圧倒的な答えではありません。標準またはソースコアを参照するかどうかに関係なく、より信頼できる回答を希望します。

いいえ、ファイル記述子0、1、2を閉じたくないのは確かです。

そうすると、アプリケーションが初めてファイルを開いたときに、stdin / stdout / stderrになります...

たとえば、次の場合：

echo text | tee file >&-

ときtee（busyboxのような、少なくともいくつかの実装は、 '）書き込み用のファイルを開くには、ファイルディスクリプタ1（標準出力）に公開されます。次のteeようにtext2回書き込みますfile。

$ echo text | strace tee file >&-
[...]
open("file", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 1
read(0, "text\n", 8193)                 = 5
write(1, "text\n", 5)                   = 5
write(1, "text\n", 5)                   = 5
read(0, "", 8193)                       = 0
exit_group(0)                           = ?

これはセキュリティの脆弱性を引き起こすことが知られています。例えば：

chsh 2>&-

また、chsh（setuidアプリケーション）でエラーメッセージを書き込むことがあります/etc/passwd。

いくつかのツールといくつかのライブラリでさえ、それを防ぐようにしています。例えば、GNU teeは、書き込みのために開くファイルに0、1、2が割り当てられ、busyboxには割り当てられない場合、ファイル記述子を2つ以上に移動しますtee。

ほとんどのツールは、stdoutに書き込めない場合（たとえば、開いていないため）、stderrにエラーメッセージを報告します（ユーザーの言語で、ローカライズファイルを開いて解析するための追加処理を意味します...）。効率が大幅に低下し、プログラムが失敗する可能性があります。

いずれにせよ、それはより効率的ではありません。プログラムは引き続きwrite()システムコールを実行します。プログラムが最初に失敗したwrite()システムコールの後にstdout / stderrへの書き込みを放棄した場合にのみ、より効率的になりますが、プログラムは一般にそうしません。通常、エラーで終了するか、試行を続けます。

IOW は、ファイルのすべてのバイトを実際に処理し、それを忘れて書き込むことを>/dev/null意味するのかどうか、いつも疑問に思っていました。cat mybigfile >/dev/null/dev/null

それはあなたの質問に対する完全な答えではありませんが、はい、上記はそれがどのように機能するかです。

cat指定されたファイル、またはファイルが指定されていない場合は標準入力を読み取り、最後に指定されたファイル（標準入力を含む）でEOFが発生するまでそれらの内容を標準出力に出力します。つまりその仕事。

追加>/dev/nullすると、標準出力が/ dev / nullにリダイレクトされます。それは特別なファイル（デバイスノード）で、そこに書き込まれたものをすべて捨てます（そして読み取り時にすぐにEOFを返します）。I / Oリダイレクトは、個々のアプリケーションではなく、シェルによって提供される機能であり、/ dev / null という名前には魔法のようなものはなく、ほとんどのUnixライクなシステムに存在するものだけです。

デバイスノードの特定のメカニズムはオペレーティングシステムごとに異なりますが、cat（GNUシステムではcoreutilsを意味する）はクロスプラットフォームであることに注意することも重要です（少なくとも LinuxとHurd）したがって、特定のオペレーティングシステムカーネルへの依存関係を取ることはできません。さらに、別の名前で/ dev / nullエイリアス（Linuxでは、これは同じメジャー/マイナーデバイス番号を持つデバイスノードを意味します）を作成した場合でも機能します。そして、同じように効果的に動作する別の場所（/ dev / zeroなど）に書き込む場合が常にあります。

したがってcat、/ dev / nullの特別なプロパティは認識されず、そもそもリダイレクトは認識されない可能性がありますが、それでもまったく同じ作業を実行する必要があります。指定されたファイルを読み取り、これらのファイルを標準出力に追加します。の標準出力がcatたまたまボイドになることは、それcat自体が懸念することではありません。