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