此处[ 1 ] [ 2 ] [ 3 ]的大多数答案使用单个尖括号重定向到/ dev / null，如下所示：
command > /dev/null
但是附加到/ dev / null也可以：
command >> /dev/null
除了多余的字符，是否有其他理由不这样做？是这些对“ / dev / null”的基础实现的“更尼克”？
编辑：
在开放式（2）手册页说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/null用一个>符号书写要短一些。
至于已编辑的附加内容：
open（2）联机帮助页说，在追加模式下每次写入文件之前，都会调用lseek。
如果仔细阅读，您会看到它说（强调我的意思）：
文件偏移量位于文件的末尾，就像使用lseek（2）
意思是，它实际上并不需要（实际上）调用lseek系统调用，并且效果也不完全相同：lseek(fd, SEEK_END, 0); write(fd, buf, size);不带调用O_APPEND与以追加模式进行写操作并不相同，因为使用单独的调用，另一个进程可以向系统调用之间的文件，将附加的数据丢弃。在附加模式下，不会发生这种情况（通过NFS除外，它不支持真正的附加模式）。
此时，标准中的文本没有提及lseek，只有写入应该放在文件的末尾。
那么，截断/ dev / null实际上是未指定的吗？
从您所引用的圣经来看，它显然是实现定义的。这意味着任何理智的实现都将与管道和TTY的实现相同，即无所作为。疯狂的实现可能会做其他事情，对于某些其他设备文件，截断可能意味着有意义的事情。
lseek调用对写入性能有影响吗？
测试一下。这是在给定系统上确定的唯一方法。或阅读源代码以查看附加模式在何处更改行为（如果有的话）。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句