/ dev / nullへのリダイレクトに単一または二重の山括弧を使用する必要がありますか？

ほとんどの回答はここ^{[ 1 ] [ 2 ] [ 3 ]で}、単一の山括弧を使用して/ dev / nullにリダイレクトします。

command > /dev/null

ただし、/ dev / nullへの追加も機能します。

command >> /dev/null

余分なキャラクターを除いて、これをしない理由はありますか？これらのいずれかは、/ dev / nullの基礎となる実装に対して「より良い」ものですか？

編集：オープン（2） manページは言うのlseekは追加モードでファイルへの各書き込みの前に呼び出されます。

O_APPEND
ファイルは追加モードで開かれます。各write（2）の前に、ファイルオフセットは、lseek（2）の場合と同様に、ファイルの末尾に配置されます。ファイルオフセットの変更と書き込み操作は、単一のアトミックステップとして実行されます。

を使用すると、パフォーマンスがわずかに低下する可能性があると思います>>。しかし、その一方で、/ dev / nullの切り捨ては、そのドキュメントによると、未定義の操作のように思われます。

O_TRUNC
ファイルが既に存在し、通常のファイルであり、アクセスモードで書き込みが許可されている場合（つまり、O_RDWRまたはO_WRONLY）、長さ0に切り捨てられます。ファイルがFIFOまたは端末デバイスファイルの場合、O_TRUNCフラグは無視されます。それ以外の場合、O_TRUNCの効果は指定されていません。

およびPOSIX仕様は述べている>既存のファイルを切り捨てるものとするが、O_TRUNCは実装定義のデバイスファイルのためであると切り捨てられることに対応すべきかを/ dev / nullには単語がありません。

したがって、/ dev / nullの切り捨ては実際には指定されていませんか？また、lseek呼び出しは書き込みパフォーマンスに影響を与えますか？

定義により/dev/null、書き込まれたものはすべてシンクされるため、追加モードで書き込むかどうかは関係ありません。すべて破棄されます。データを保存しないため、実際に追加するものはありません。

そのため、最終的には、> /dev/null1つの>記号で書くほうが短くなります。

編集された追加に関して：

open（2）マンページには、追加モードでファイルに書き込むたびにlseekが呼び出されると書かれています。

よく読んでみると、次のように表示されます（私の強調）：

ファイルオフセットは、 lseek（2）の場合と同様に、ファイルの末尾に配置されます。

意味、それは（する必要があります）、実際に呼び出していないlseekシステムコールは、その効果はどちらか厳密に同じではありません。呼び出すlseek(fd, SEEK_END, 0); write(fd, buf, size);ことなく、O_APPEND追加モードでの書き込みと同じではありません別の呼び出しで別のプロセスが書き込み可能性があるので、システムコールの間にファイルを追加し、追加されたデータを破棄します。追加モードでは、これは起こりません（実際の追加モードをサポートしないNFSを除く）。

標準のテキストはlseekその時点では言及しておらず、書き込みのみがファイルの最後になります。

それで、/ dev / nullの切り捨ては実際には指定されていませんか？

あなたが参照する聖句から判断すると、明らかにそれは実装定義です。正しい実装は、パイプやTTYの場合と同じ、つまり何もしないという意味です。非常識な実装は他の何かをするかもしれません、そしておそらく切り捨ては他のデバイスファイルの場合には賢明な何かを意味するかもしれません。

また、lseek呼び出しは書き込みパフォーマンスに影響を与えますか？

試して。特定のシステムで確実に知る唯一の方法です。または、ソースを読んで、追加モードが動作を変更する場所を確認します（ある場合）。

必要な場合は、command >&-代わりに使用してください。これにより、ファイル記述子がリダイレクトされるのではなく閉じられるため、物を書き込む時間を無駄にすることはありません。