Debido a que los mensajes de error a menudo stderr
nostdout
.
Cambie la invocación a esto:
taskkill /im "test.exe" /f >nul 2>&1
y todo irá mejor.
Eso funciona porque stdout
es el descriptor de archivo 1 y stderr
es el descriptor de archivo 2 por convención. (0 es stdin
, dicho sea de paso.) El 2>&1
descriptor de archivo de salida de copias 2 del nuevo valor de 1, que acaba de ser redirigido al dispositivo nulo.
Esta sintaxis se toma prestada (libremente) de muchos shells de Unix, pero debe tener cuidado porque hay diferencias sutiles entre la sintaxis de shell y CMD.EXE.
Actualización: Sé que el OP entiende la naturaleza especial del "archivo" llamado al NUL
que estoy escribiendo aquí, pero un comentarista no lo hizo, así que permítanme divagar con un poco más de detalle sobre ese aspecto.
Remontándonos hasta las primeras versiones de MSDOS, el kernel del sistema de archivos se apropió de ciertos nombres de archivo y se usaron para hacer referencia a dispositivos. La primera lista de los nombres incluidos NUL
, PRN
, CON
, AUX
y COM1
a través COM4
. NUL
es el dispositivo nulo. Siempre se puede abrir para leer o escribir, se puede escribir cualquier cantidad en él, y las lecturas siempre se realizan correctamente pero no devuelven datos. Los otros incluyen el puerto de impresora paralelo, la consola y hasta cuatro puertos seriales. A partir de MSDOS 5, había varios nombres más reservados, pero la convención básica estaba muy bien establecida.
Cuando se creó Windows, comenzó su vida como una capa de conmutación de aplicaciones bastante delgada sobre el kernel de MSDOS y, por lo tanto, tenía las mismas restricciones de nombre de archivo. Cuando se creó Windows NT como un verdadero sistema operativo por derecho propio, se asumió demasiado ampliamente que los nombres como NUL
y COM1
funcionaban como para permitir su eliminación. Sin embargo, la idea de que los nuevos dispositivos siempre obtendrían nombres que bloquearían a los futuros usuarios de esos nombres para archivos reales es obviamente irrazonable.
Windows NT y todas las versiones siguientes (2K, XP, 7 y ahora 8) utilizan el espacio de nombres NT mucho más elaborado del código del kernel y un código de espacio de usuario cuidadosamente construido y altamente no portátil. En ese espacio de nombres, los controladores de dispositivos son visibles a través de la \Device
carpeta. Para admitir la compatibilidad con versiones anteriores requerida, existe un mecanismo especial que utiliza la \DosDevices
carpeta que implementa la lista de nombres de archivos reservados en cualquier carpeta del sistema de archivos. El código de usuario puede examinar este espacio de nombres interno utilizando una capa de API debajo de la API Win32 habitual; una buena herramienta para explorar el espacio de nombres del kernel es WinObj del grupo SysInternals de Microsoft.
Para obtener una descripción completa de las reglas que rodean los nombres legales de archivos (y dispositivos) en Windows, esta página en MSDN será informativa y desalentadora. Las reglas son mucho más complicadas de lo que deberían ser, y en realidad es imposible responder algunas preguntas simples como "¿cuánto tiempo es el nombre de ruta legal completamente calificado más largo?".