cmd.exe重定向运算符顺序和位置

先谈订单

以下操作可将

stdout

和

strerr

重定向到

nul

command 1>nul 2>&1

以下内容并不适用

command 2>&1 1>nul

为什么顺序很重要？如何用人类可以理解的语言来解读这些表达

关于职位

这很有效

command 1>nul 2>&1

还有这个

1>nul 2>&1 command

---

为什么?？任何关于语法规则的官方参考文档都会有所帮助

CMD

只是从

MSDOS 5

模拟

command.com

。添加的额外设施作为“外壳”应用，封装现有功能和怪癖，以确保现有批次受到的影响最小

开发人员做出了许多令人费解的决定。这似乎是一个低优先级、监督不力的项目，内置文档中的拼写糟糕且不一致就是明证，决定将前导零字符串解释为八进制而不是十进制，而不是使用类似于十六进制的

O'123'

。日期/时间实用程序中没有通用日期格式的

/u

开关，还有许多其他需要解决的怪癖——所有这些都指向一个管理不善的项目，交给了一个在商业编程现实中毫无血气的傲慢开发人员

因此，

2&1

语法是一个附加组件，应用于一个产品时效果不佳，人们希望它会在点击和咯咯笑产生的压力下消失。因此，这并不是“工业实力”——但讽刺的是，它仍然存在

事实上，在过去十年或更长的时间里几乎没有进一步的发展，这表明了它的“穷表亲”地位。它没有钱，因为它不华而不实，而且由于向后兼容，它的思维必然最终植根于20世纪50年代

因此，没有任何商业理由需要解决DOS5后改进带来的异常。序列问题的出现是因为程序员的思维方式，没有考虑到任何人会试图以任何其他方式使用新的设施，而不是以特定程序员认为合乎逻辑的方式

---

因此，您可以按照程序员决定的方式使用重定向，而且短期内不可能改变这种情况-除非您能拿出几百万美元来资助您所需的开发。

command 2>&1>nul

不起作用是不正确的。它起作用了。但和往常一样，它只做你要求的，而不是你想要的

从左到右：

• 2>&1

  流2（stderr）的数据将被发送到流1（stdout）正在使用的句柄的副本

• 1>nul

  流1中的数据将发送到

  nul

复制品是关键。数据不会发送到任何流1点，而是发送到流句柄的副本。当重定向流1时，流2有自己的句柄，即前一个流1的副本。更改流1不会影响流2

现在，让我们看看工作代码，从左到右

• 1>nul

  将流1中的句柄设置为指向nul

• 2>&1

  将流2中的句柄设置为流1中使用的句柄的副本，即，将句柄设置为

  nul

关于职位

大多数情况下，位置（命令前、命令后或两者）是无关的。要执行命令，解析器必须首先准备命令将使用的流。在开始执行命令之前，如果认为有必要（尝试重定向

rem

命令输入或输出），可以进行此准备

唯一不同的情况是，我们希望从命令中获得的内容与解析器理解的内容不一样。一种明显的情况是，我们需要输出一个带有结尾数字的字符串。代码为

echo 1 2 3>file 

不会将完整字符串发送到目标文件<代码>1 2将回显到控制台，写入流3的数据（此命令中没有任何内容）将发送到

文件

当然，可以在数据末尾添加空格（介于

3

和

之间），但此空格将包含在输出中。如果这是不可接受的，解决方案是将重定向放在命令的开头

>file echo 1 2 3

---

嗯

2>&1

，所以如果你认为这是一个不可理解的决定，你可以向肯·汤普森提出。@RaymondChen:我没有说过

2>&1

是不可理解的。我说过选择前导-0是八进制而不是十进制，

H'xx'

是十六进制，但

O'xx'

不是八进制；缺少通用日期格式、不一致的

errorlevel

设置、部分

regex

执行和其他做出的决定-这些都是不可理解的。要求

a>&b

和

b>nul

按特定顺序，而不是按任何顺序应用开关和指令的一般原则。这些决定令人费解。订购要求与UNIX相同。下次有人抱怨“为什么Microsoft必须发明一种非标准的方式来做每件事？”时，我会记住这一点。@JaimeHablutzel请参阅Kernighan和Pike的“UNIX编程环境”。维基百科的文章也解释了这一点<代码>2>&1>文件将错误发送到标准输出并输出到文件<代码>>文件2>&1向文件发送错误和输出。就像在编程语言中一样，顺序很重要，

x=y；y=2不同于
y=2；x=y绝对清晰的解释，我用
1>nul2>&1
来抑制输出，甚至一辈子都不理解它，可能是因为我从来没有找到更好的解释。但是，t呢