Suppress command line output
I have a simple batch file:
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 is this error message displayed even though I redirected the output to NUL?
How can I suppress this conclusion?
Because error messages often go to stderr not stdout .
Modify the call as follows:
taskkill /im "test.exe" /f >nul 2>&1 and everything will be better.
This works because stdout is file descriptor 1, and stderr is file descriptor 2 by convention. (0 is stdin , by the way.) 2>&1 copies the output descriptor of file 2 from the new value 1, which was simply redirected to the null device.
This syntax is (freely) borrowed from many Unix shells, but you have to be careful because there are subtle differences between the shell syntax and CMD.EXE.
Update: I know that the OP understands the special nature of the “file” with the name NUL , which I write here, but the commentator did not, and so let me digress a little more in detail about this.
Returning to the earliest releases of MSDOS, some file names were uploaded by the kernel of the file system and used to indicate devices. The earliest list of these names included NUL , PRN , CON , AUX and COM1 through COM4 . NUL is a null device. It can always be opened for reading or writing, any amount can be written on it and is always read, but does not return any data. Others include a parallel printer port, a console, and up to four serial ports. As for MSDOS 5, there were a few more reserved names, but the basic convention was very well established.
When Windows was created, it started working as a fairly thin layer of application switching on top of the MSDOS kernel, and thus had the same file name restrictions. When Windows NT was created as a true operating system on its own, names like NUL and COM1 were all too widely considered working to fix them. However, the idea that new devices will always receive names that block the future user of these names for actual files is clearly unfounded.
Windows NT and all versions that follow (2K, XP, 7 and now 8) follow the use of the much more complex NT Namespace from the kernel code and carefully designed and highly independent user space code. In this namespace, device drivers are visible through the \Device folder. To support the required backward compatibility, there is a special mechanism using the \DosDevices folder, which implements a list of reserved file names in any folder of the file system. User code can view this internal namespace using an API level below the regular Win32 API; A good tool for exploring the kernel namespace is WinObj from the SysInternals group at Microsoft.
For a complete description of the rules associated with legal file names (and devices) on Windows, this MSDN page will be both informative and intimidating. The rules are much more complicated than they should be, and it is actually impossible to answer some simple questions, such as "how long is this long legal full path name?".
Use a script instead:
@taskkill/f /im test.exe >nul 2>&1 @pause What part 2>&1 actually does is that it redirects the output of stderr to stdout . I will explain it below:
@ taskkill / f / im test.exe> nul 2> & 1
Kill the "test.exe" task. Redirect stderr to stdout . Then redirect stdout to nul .
@pause
Show pause message Press any key to continue . . . Press any key to continue . . . until someone presses a key.
NOTE. The @ symbol hides the invitation for each command. This way you can store up to 8 bytes.
The shortest version of your script could be:@taskkill/f /im test.exe >nul 2>&1&pause
The & character is used to redirect the first time and to separate commands the second time.
The @ character is not required twice per line. This code is only 40 bytes, despite the fact that you have placed 49 bytes! I actually saved 9 bytes. For a cleaner code, see above.
You can also do this:
tasklist | find /I "test.exe" > nul && taskkill /f /im test.exe > nul mysqldump does not work with: > nul 2> & 1
Use: 2> nul instead
This suppresses the stderr message: "Warning: using a password in the command line interface may be unsafe"