98

我对这个表达有点困惑：

gcc -c -g program.c >& compiler.txt

我知道&>filename会将 stdout 和 stderr 都重定向到 file filename。但在这种情况下，& 符号位于大于号之后。它看起来像它的形式M>&N，其中M和N是文件描述符。

在上面的片段中，doM=1和N='compiler.txt'? 这与以下具体有何不同：

gcc -c -g program.c > compiler.txt     (ampersand removed)

我的理解是每个打开的文件都与大于 2 的文件描述符相关联。这是正确的吗？

如果是这样，作为重定向目标的文件名是否可以与其文件描述符互换？

4

2 回答 2

111

这与&>. 从 bash 手册页：

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

There are two formats for  redirecting  standard  output  and  standard
error:

       &>word
and
       >&word

Of the two forms, the first is preferred.  This is semantically equiva-
lent to

       >word 2>&1
于 2012-06-29T02:57:19.930 回答
19

&>vs >&: 首选版本是&>(clobber)

关于：

  • &>
  • >&

两者都会破坏文件 - 在写入之前将文件截断为 0 字节，就像> file在仅 STDIN 的情况下所做的那样。

但是，bash手动重定向部分补充说：

在这两种形式中，首选第一种。这在语义上等价于

>word 2>&1

使用第二种形式时，word不能扩展为数字或-. 如果是这样，出于兼容性原因，将应用其他重定向运算符（请参阅下面的复制文件描述符）。

（注意：两者zsh都是等价的。）

以第一种 ( ) 形式获取手指记忆是非常好的做法&>，因为：

（附加）不支持使用&>>as>>&bash

只有一种附加形式：

附加标准输出和标准错误的格式是：

&>>word

这在语义上等价于

>>word 2>&1

（请参阅下面的复制文件描述符）。

笔记：

  • 鉴于只有一种追加 in 的方法，再次建议使用上面部分中的&>over的 clobber 用法。>&bash
  • zsh允许两者&>>和>>&形式。
于 2018-06-30T06:39:33.510 回答