Parce que les messages d'erreur vont souvent stderr
pas stdout
.
Changez l'invocation en ceci:
taskkill /im "test.exe" /f >nul 2>&1
et tout ira mieux.
Cela fonctionne parce que stdout
le descripteur de fichier 1 et stderr
le descripteur de fichier 2 par convention. (0 est stdin
, d'ailleurs.) La 2>&1
copie du descripteur de fichier de sortie 2 à partir de la nouvelle valeur de 1, qui vient d'être redirigée vers le périphérique nul.
Cette syntaxe est (vaguement) empruntée à de nombreux shells Unix, mais vous devez être prudent car il existe des différences subtiles entre la syntaxe du shell et CMD.EXE.
Mise à jour: Je sais que l'OP comprend la nature particulière du "fichier" nommé NUL
dans lequel j'écris ici, mais un commentateur ne l'a pas fait et permettez-moi donc de m'éloigner un peu plus de cet aspect.
En remontant jusqu'aux premières versions de MSDOS, certains noms de fichiers ont été préemptés par le noyau du système de fichiers et utilisés pour désigner des périphériques. La première liste de ces noms inclus NUL
, PRN
, CON
, AUX
et à COM1
travers COM4
. NUL
est le périphérique nul. Il peut toujours être ouvert en lecture ou en écriture, n'importe quel montant peut y être écrit et les lectures réussissent toujours mais ne renvoient aucune donnée. Les autres incluent le port d'imprimante parallèle, la console et jusqu'à quatre ports série. À partir de MSDOS 5, il y avait plusieurs autres noms réservés, mais la convention de base était très bien établie.
Lorsque Windows a été créé, il a commencé sa vie comme une couche de commutation d'application assez mince au-dessus du noyau MSDOS, et avait donc les mêmes restrictions de nom de fichier. Lorsque Windows NT a été créé comme un véritable système d'exploitation à part entière, les noms comme NUL
et COM1
étaient trop largement supposés fonctionner pour permettre leur élimination. Cependant, l'idée que les nouveaux appareils obtiendraient toujours des noms qui bloqueraient les futurs utilisateurs de ces noms pour les fichiers réels est évidemment déraisonnable.
Windows NT et toutes les versions qui suivent (2K, XP, 7 et maintenant 8) utilisent tous l' espace de noms NT beaucoup plus élaboré à partir du code du noyau et du code d'espace utilisateur soigneusement construit et hautement non portable. Dans cet espace de nom, les pilotes de périphérique sont visibles dans le \Device
dossier. Pour prendre en charge la compatibilité descendante requise, il existe un mécanisme spécial utilisant le \DosDevices
dossier qui implémente la liste des noms de fichiers réservés dans n'importe quel dossier du système de fichiers. Le code utilisateur peut parcourir cet espace de nom interne en utilisant une couche API sous l'API Win32 habituelle; WinObj du groupe SysInternals de Microsoft est un bon outil pour explorer l'espace de noms du noyau .
Pour une description complète des règles entourant les noms légaux des fichiers (et des périphériques) dans Windows, cette page sur MSDN sera à la fois informative et intimidante. Les règles sont beaucoup plus compliquées qu'elles ne devraient l'être, et il est en fait impossible de répondre à quelques questions simples telles que "combien de temps dure le nom de chemin complet légal le plus long?".