batch-file - 抑制命令行输出

Question

我有一个像这样的简单批处理文件:

echo offtaskkill /im "test.exe" /f > nulpause

如果“test.exe”未运行，我会收到以下消息:

ERROR: The process "test.exe" not found.

即使我已将输出重定向到 NUL，为什么仍会显示此错误消息？

如何抑制该输出？

Answer 1

因为错误消息通常会发送到 stderr 而不是 stdout。

将调用更改为:

taskkill /im "test.exe" /f >nul 2>&1

一切都会变得更好。

这是可行的，因为按惯例，stdout 是文件描述符 1，而 stderr 是文件描述符 2。 (顺便说一句，0 是 stdin。)2>&1 从新值 1 复制输出文件描述符 2，该值刚刚重定向到空设备。

此语法(松散地)借用自许多 Unix shell，但您必须小心，因为 shell 语法和 CMD.EXE 之间存在细微差别。

更新:我知道OP理解我正在写到这里的名为NUL的"file"的特殊性质，但评论者不明白，所以让我离题了，在这方面提供更多细节。

一直追溯到 MSDOS 的最早版本，某些文件名被文件系统内核抢占并用于引用设备。这些名称的最早列表包括 NUL、PRN、CON、AUX 和 COM1 > 通过 COM4。 NUL 是空设备。它始终可以打开以进行读取或写入，可以在其上写入任何数量，并且读取总是成功但不返回任何数据。其他端口包括并行打印机端口、控制台和最多四个串行端口。从 MSDOS 5 开始，还有几个保留名称，但基本约定已经非常完善。

当 Windows 创建时，它最初是作为 MSDOS 内核之上的一个相当薄的应用程序交换层，因此具有相同的文件名限制。当 Windows NT 被创建为一个真正的操作系统时，诸如 NUL 和 COM1 之类的名称被广泛认为无法发挥作用，因此无法消除它们。然而，认为新设备总会获得会阻止 future 用户使用这些名称来获取实际文件的名称的想法显然是不合理的。

Windows NT 和后续的所有版本(2K、XP、7 和现在的 8)都使用更精细的 NT Namespace从内核代码到精心构造且高度不可移植的用户空间代码。在该命名空间中，设备驱动程序通过 \Device 文件夹可见。为了支持所需的向后兼容性，有一种特殊的机制，使用 \DosDevices 文件夹来实现任何文件系统文件夹中的保留文件名列表。用户代码可以使用通常的 Win32 API 下面的 API 层来浏览这个内部 namespace ；探索内核命名空间的一个好工具是 WinObj来自 Microsoft 的 SysInternals 小组。

有关 Windows 中文件(和设备)合法名称的规则的完整说明，this page at MSDN既会提供丰富的信息，又会令人畏惧。这些规则比应有的复杂很多，并且实际上不可能回答一些简单的问题，例如“最长的合法完全限定路径名有多长？”。