> & amp？

我被这句话弄糊涂了:

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

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

在上面的代码片段中，做 M=1和 N='compiler.txt'? 这与下面的代码片段到底有什么不同:

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

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

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

51621 次浏览
小开
最佳答案

这与 &>相同:

重定向标准输出和标准错误 这个结构允许标准输出(文件描述符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
小开

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

关于:

  • &>
  • >&

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

然而，手动重定向部分补充说:

在这两种形式中，首选形式

>word 2>&1

当使用第二种形式时，字可能不会展开为数字或者 -。如果是这样，出于兼容性原因，其他重定向操作符将应用(请参见下面的复制文件描述符)。

(注: 在 zsh中两者是等价的)

训练你的手指使用第一式(&>)是一个很好的练习，因为:

使用 &>>，因为 bash不支持 >>&(附录)

只有一个附加表格:

The format for appending standard output and standard error is:

&>>word

这在语义上等同于

>>word 2>&1

(请参阅下面的文件描述符复制)。

Note:

  • 考虑到在 bash中只有一种附加方法，因此再次推荐在上一节中使用 &>而不是 >&。
  • zsh allows both &>> and >>& forms.
小开

有点跑题，但这就是为什么我一直坚持像 >/dev/null 2>&1这样的长格式。 That is confusing enough for people who do it backwards in things like cron without adding >&, &>, >>&, &>>, ... on top of it. 我经常需要在 crontab -l中添加注释，提醒人们“2 > & 1 >/dev/null”不是最佳实践。

只要您记得任何“最终目的地”都是先给定的，那么在任何 Unix 或类 Unix 系统上使用任何类 Bourne shell 的语法都应该是相同的，无论是附加的还是其他的。 另外，由于 &>实际上是一个 Bash 主义(可能起源于 csh？不记得了，但无论如何都不是 POSIX) ，它并不总是在锁定的商业 UNIX 系统上受支持。


提交答案