Perché i messaggi di errore spesso vanno a stderrno stdout.
Cambia l'invocazione in questo:
taskkill /im "test.exe" /f >nul 2>&1
e tutto andrà meglio.
Funziona perché stdoutè il descrittore di file 1 ed stderrè il descrittore di file 2 per convenzione. (0 è stdin, incidentalmente.) 2>&1Copia il descrittore del file di output 2 dal nuovo valore 1, che è stato appena reindirizzato al dispositivo nullo.
Questa sintassi è (vagamente) presa in prestito da molte shell Unix, ma devi stare attento perché ci sono sottili differenze tra la sintassi della shell e CMD.EXE.
Aggiornamento: so che l'OP comprende la natura speciale del "file" a NULcui sto scrivendo qui, ma un commentatore non l'ha fatto e quindi lasciatemi divagare con un po 'più di dettaglio su questo aspetto.
Tornando alle prime versioni di MSDOS, alcuni nomi di file erano preceduti dal kernel del file system e usati per fare riferimento ai dispositivi. Il primo elenco di quei nomi inclusi NUL, PRN, CON, AUXe COM1attraverso COM4. NULè il dispositivo nullo. Può sempre essere aperto per la lettura o la scrittura, qualsiasi importo può essere scritto su di esso e le letture riescono sempre ma non restituiscono dati. Gli altri includono la porta della stampante parallela, la console e fino a quattro porte seriali. A partire da MSDOS 5, c'erano molti altri nomi riservati, ma la convenzione di base era molto ben stabilita.
Quando è stato creato Windows, ha iniziato la sua vita come uno strato di commutazione dell'applicazione piuttosto sottile sopra il kernel MSDOS, e quindi aveva le stesse restrizioni sul nome del file. Quando Windows NT è stato creato come un vero sistema operativo a sé stante, si presumeva troppo spesso che nomi simili NULe COM1funzionassero per consentirne l'eliminazione. Tuttavia, l'idea che i nuovi dispositivi otterrebbero sempre nomi che bloccherebbero l'utente futuro di quei nomi per i file effettivi è ovviamente irragionevole.
Windows NT e tutte le versioni successive (2K, XP, 7 e ora 8) utilizzano lo spazio dei nomi NT molto più elaborato dal codice del kernel e un codice spazio utente attentamente costruito e altamente non portabile. In quello spazio dei nomi, i driver di dispositivo sono visibili attraverso la \Devicecartella. Per supportare la compatibilità con le versioni precedenti richiesta esiste un meccanismo speciale che utilizza la \DosDevicescartella che implementa l'elenco dei nomi di file riservati in qualsiasi cartella del file system. Il codice utente può esplorare questo spazio dei nomi interno utilizzando un livello API sotto la consueta API Win32; un buon strumento per esplorare lo spazio dei nomi del kernel è WinObj del gruppo SysInternals di Microsoft.
Per una descrizione completa delle regole che circondano i nomi legali dei file (e dei dispositivi) in Windows, questa pagina su MSDN sarà sia informativa che scoraggiante. Le regole sono molto più complicate di quanto dovrebbero essere, ed è effettivamente impossibile rispondere ad alcune semplici domande come "quanto è lungo il nome di percorso pienamente qualificato legale più lungo?".