Потому что сообщения об ошибках часто отправляются в stderr
not stdout
.
Измените вызов на это:
taskkill /im "test.exe" /f >nul 2>&1
и все будет лучше.
Это работает, потому что stdout
это дескриптор файла 1 и stderr
дескриптор файла 2 по соглашению. (Кстати stdin
, 0. ) 2>&1
Дескриптор выходного файла 2 копируется из нового значения 1, которое было только что перенаправлено на нулевое устройство.
Этот синтаксис (вольно) заимствован из многих оболочек Unix, но вы должны быть осторожны, потому что есть тонкие различия между синтаксисом оболочки и 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
папку, который реализует список зарезервированных имен файлов в любой папке файловой системы. Пользовательский код может просматривать это внутреннее пространство имен, используя уровень API ниже обычного Win32 API; Хорошим инструментом для изучения пространства имен ядра является WinObj от группы SysInternals в Microsoft.
Чтобы получить полное описание правил, касающихся законных имен файлов (и устройств) в Windows, эта страница в MSDN будет как информативной, так и пугающей. Правила намного сложнее, чем они должны быть, и на самом деле невозможно ответить на некоторые простые вопросы, такие как «какова длина самого длинного допустимого полного имени пути?».