☰

&> >& 和 2>&1 之间的重定向差异

tag-icon • tag-icon shell zsh io-redirection
&> >& 和 2>&1 之间的重定向差异

在这个所以线程和其他一些线程我看到了以下用于重定向stdout和stderr到文件的命令。

它们都是等价的吗？他们之间有什么区别吗？

command1 >> logfile 2>&1
command &> logfile
command >& logfile

答案1

既然您已经标记了zsh，那么让我告诉您，所有 3 个重定向的工作方式完全相同。正如您可能已经阅读过的两篇重复帖子（评论中的帖子和您帖子中的帖子）一样，它们都重定向stderr到stdout哪个又重定向到文件“日志文件”（即，日志文件将包含输出和错误）。

但它们的行为会根据您所在的 shell 发生很大变化。

bash所有三种重定向方式在和中都以相同的方式工作良好zsh

但：

仅>&适用于csh或tcsh

[soum@server ~]$  ./test.sh > logfile 2>&1
Ambiguous output redirect.
[soum@server ~]$ ./test.sh &> logfile
Invalid null command.
[soum@server ~]$ ./test.sh >& logfile
[soum@server ~]$ echo $SHELL
/bin/tcsh
[soum@server ~]$

ksh仅在2>&1作品中。

$ ./test.sh >& logfile
-ksh: logfile: bad file unit number
$ ./test.sh &> logfile
[1]     23039
$ 1  2  3  4  5  6  logfile  test.sh
ls: cannot access ttr: No such file or directory

[1] +  Done(2)                 ./test.sh &> logfile

我恨ksh。虽然>&刚刚给出了一个错误，但&>该命令的一部分已后台运行并清空了日志文件（如果非空）。

答案2

&>和>&半等价（clobber）

这zsh手动重定向部分说：

  • &>
  • >&

是等价的。

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

然而， 这bash手动重定向部分补充说：

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

>word 2>&1

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

因此，当您标记 时zsh，如果有人编写脚本，以第一种形式获得手指记忆可能是一个很好的做法bash。

>> logfile 2>&1和&>>等价（附加）

这里，logfile不是被覆盖，而是在文件末尾打开写入，即追加模式（O_APPEND）。

两者的等价物{ba,z}sh是：

command1 &>> logfile

在bash：

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

&>>word

这在语义上等价于

>>word 2>&1

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

（注意：鉴于只有一种追加方法，再次建议在上面的部分中使用&>over 。）>&bash

zsh允许同时使用&>>和>>&形式。

相关内容