为什么>>＆和＆>>之间有区别，但>＆和＆>之间没有区别？

Question

从bash man pages的“重定向”部分下：

  

重定向标准输出和标准错误

     

此结构允许将标准输出（文件描述符1）和标准错误输出（文件描述符2）都重定向到名称为word扩展名的文件。

     

重定向标准输出和标准错误有两种格式：

     

＆>单词

     

和

     

>＆word

     

在两种形式中，第一种是首选。

这让我感到奇怪，为什么第一个首选？我看到&>>有效，但>>&无效，因此首选项有意义。那么，>>&为什么不起作用？ big昧吗？

---

这就是我正在跑步的

$ bash --version
GNU bash, version 4.2.46(1)-release (x86_64-redhat-linux-gnu)

Answer 1

&>dest毫无疑问，而>&dest看起来像fdup()的语法...如果您有一个fdup语法，可以将其解释为数字文件名。

从4.1或更高版本开始，Bash允许对fdup操作的目标进行参数化-因此，不仅2>&1，而且2>&$stderr_fd也可以被参数化。将&放在>之后会把我们置于fdup()操作所用语法的名称空间中；事先保留它是明确的。

示例：我想将命令cmd的stdout和stderr重定向到我的文件中。如果我的文件名为0，则>&会引起问题。

• cmd >& 0成为cmd 1>&0。也就是说，将stdout重定向到fd＃0。
• cmd &> 0成为cmd > 0 2>&1。也就是说，将stdout重定向到名为0的文件，然后将stderr重定向到fd＃1。

---

[n]>&word是POSIX标准化的；在POSIX标准的任何地方都找不到&>word。

用于复制现有文件描述符defined by the POSIX standard的唯一形式是[n]<&word和[n]>&word。在语法中，这些标记被赋予了令牌名称GREATAND和LESSAND。

&>或&<没有POSIX定义的令牌-它们只是“我不想在屏幕上看到任何东西”或“将stdout和stderr发送到文件”。

这很有用，因为cmd 2>&1 > myFile（对于刚接触bash的人来说是令人惊讶的）不能按“清洁屏幕”目标的预期工作，而cmd > myFile 2>&1，却可以

---

那么..为什么&>>不能工作，>>&却能工作吗？因为写过&>>的人都不认为需要创建歧义，所以有意识地选择不允许>>&。

fdup()与>>的同义词不会增加价值。

要进一步说明为什么 [n]>&word是毫无意义的-请记住，>bar和>>bar之间的区别在于存在O_APPEND的{​​{1}}参数中的O_TRUNC标志和flags的不存在。但是，当您提供文件描述符编号-从而从旧的FD编号执行open()到新的FD编号时-文件已打开；因此，这些标志不能更改。甚至fdup()与>的方向对读者来说也是纯粹的信息。