禁止命令行输出 [英] Suppress command line output

问题描述

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

<前>回声关闭taskkill/im "test.exe"/f > nul暂停

如果test.exe"没有运行，我会收到这条消息:

<前>错误:找不到进程test.exe".

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

如何抑制该输出?

解决方案

因为错误消息通常会转到 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 的文件"的特殊性质，我正在写信给这里，但评论者没有，所以让关于这方面的更多细节，我离题了.

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

当 Windows 被创建时，它开始作为 MSDOS 内核之上的一个相当薄的应用程序切换层，因此具有相同的文件名限制.当 Windows NT 被创建为一个真正的操作系统时，诸如 NUL 和 COM1 之类的名称被广泛认为是行不通的，以至于不允许将它们消除.然而，新设备总是会获得会阻止实际文件的这些名称的未来用户的名称的想法显然是不合理的.

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

有关 Windows 中文件(和设备)合法名称规则的完整说明，MSDN 上的这个页面 既提供信息又令人生畏.规则比它们应有的要复杂很多，实际上无法回答一些简单的问题，例如最长的合法完全限定路径名有多长?".

I have a simple batch file like this:

echo off

taskkill /im "test.exe" /f > nul

pause

If "test.exe" is not running, I get this message:

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

Why does this error message get displayed, even though I have redirected output to NUL?

How can I suppress that output?

解决方案

Because error messages often go to stderr not stdout.

Change the invocation to this:

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

and all will be better.

That works because stdout is file descriptor 1, and stderr is file descriptor 2 by convention. (0 is stdin, incidentally.) The 2>&1 copies output file descriptor 2 from the new value of 1, which was just redirected to the null device.

This syntax is (loosely) borrowed from many Unix shells, but you do have to be careful because there are subtle differences between the shell syntax and CMD.EXE.

Update: I know the OP understands the special nature of the "file" named NUL I'm writing to here, but a commenter didn't and so let me digress with a little more detail on that aspect.

Going all the way back to the earliest releases of MSDOS, certain file names were preempted by the file system kernel and used to refer to devices. The earliest list of those names included NUL, PRN, CON, AUX and COM1 through COM4. NUL is the null device. It can always be opened for either reading or writing, any amount can be written on it, and reads always succeed but return no data. The others include the parallel printer port, the console, and up to four serial ports. As of MSDOS 5, there were several more reserved names, but the basic convention was very well established.

When Windows was created, it started life as a fairly thin application switching layer on top of the MSDOS kernel, and thus had the same file name restrictions. When Windows NT was created as a true operating system in its own right, names like NUL and COM1 were too widely assumed to work to permit their elimination. However, the idea that new devices would always get names that would block future user of those names for actual files is obviously unreasonable.

Windows NT and all versions that follow (2K, XP, 7, and now 8) all follow use the much more elaborate NT Namespace from kernel code and to carefully constructed and highly non-portable user space code. In that name space, device drivers are visible through the Device folder. To support the required backward compatibility there is a special mechanism using the DosDevices folder that implements the list of reserved file names in any file system folder. User code can brows this internal name space using an API layer below the usual Win32 API; a good tool to explore the kernel namespace is WinObj from the SysInternals group at Microsoft.

For a complete description of the rules surrounding legal names of files (and devices) in Windows, this page at MSDN will be both informative and daunting. The rules are a lot more complicated than they ought to be, and it is actually impossible to answer some simple questions such as "how long is the longest legal fully qualified path name?".

这篇关于禁止命令行输出的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！