batch-file - una - guardar salida de un comando en un archivo linux
Suprime la salida de línea de comando (4)
Use este script en su lugar:
@taskkill/f /im test.exe >nul 2>&1
@pause
Lo que realmente hace la parte 2>&1 , es que redirige la salida de stderr a stdout . Lo explicaré mejor a continuación:
@ taskkill / f / im test.exe> nul 2> & 1
Mata a la tarea "test.exe". Redirige stderr a stdout . Luego, redirija la stdout nul a nul .
@pausa
Mostrar el mensaje de pausa Press any key to continue . . . Press any key to continue . . . hasta que alguien presione una tecla.
NOTA: El símbolo @ oculta el aviso para cada comando. Puede guardar hasta 8 bytes de esta manera.
La versión más corta de su script podría ser:
@taskkill/f /im test.exe >nul 2>&1&pause
El carácter & se usa para la redirección la primera vez y para separar los comandos la segunda vez.
Un caracter @ no es necesario dos veces en una línea. ¡Este código tiene solo 40 bytes, a pesar de que el que ha publicado tiene 49 bytes! De hecho, guardé 9 bytes. Para un código más limpio mira arriba.
Tengo un archivo por lotes simple como este:
echo off taskkill /im "test.exe" /f > nul pause
Si "test.exe" no se está ejecutando, recibo este mensaje:
ERROR: The process "test.exe" not found.
¿Por qué se muestra este mensaje de error, aunque he redirigido la salida a NUL?
¿Cómo puedo suprimir esa salida?
Usted también puede hacer esto:
tasklist | find /I "test.exe" > nul && taskkill /f /im test.exe > nul
mysqldump no funciona con: > nul 2> & 1
En su lugar use: 2> nul
Esto suprime el mensaje stderr: "Advertencia: el uso de una contraseña en la interfaz de línea de comando puede ser inseguro"
Porque los mensajes de error a menudo van a stderr no a stdout .
Cambiar la invocación a esto:
taskkill /im "test.exe" /f >nul 2>&1
y todo será 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 descriptor 2 del archivo de salida 2>&1 copia del nuevo valor de 1, que acaba de ser redirigido al dispositivo nulo.
Esta sintaxis se toma (vagamente) de muchos shells de Unix, pero hay que tener cuidado porque hay diferencias sutiles entre la sintaxis del shell y CMD.EXE.
Actualización: Sé que el OP entiende la naturaleza especial del "archivo" llamado NUL que estoy escribiendo aquí, pero un comentarista no lo hizo y así me permite hacer una digresión con un poco más de detalle sobre ese aspecto.
Volviendo a los primeros lanzamientos de MSDOS, ciertos nombres de archivos fueron reemplazados por el kernel del sistema de archivos y utilizados para referirse a los dispositivos. La lista más antigua de esos nombres incluía NUL , PRN , CON , AUX y COM1 a COM4 . NUL es el dispositivo nulo. Siempre se puede abrir para leer o escribir, se puede escribir cualquier cantidad y las lecturas siempre tienen éxito, pero no devuelven datos. Los otros incluyen el puerto paralelo de la impresora, la consola y hasta cuatro puertos serie. A partir de MSDOS 5, había muchos más nombres 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 MSDOS, y por lo tanto tenía las mismas restricciones de nombre de archivo. Cuando Windows NT se creó como un verdadero sistema operativo por derecho propio, se asumió demasiado que nombres como NUL y COM1 funcionaban 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 los archivos reales es obviamente irrazonable.
Windows NT y todas las versiones que siguen (2K, XP, 7 y ahora 8) siguen el uso del mucho más elaborado NT Namespace del código kernel y del código de espacio de usuario cuidadosamente construido y altamente no portátil. En ese espacio de nombre, los controladores del dispositivo son visibles a través de la carpeta /Device . Para admitir la compatibilidad hacia atrás requerida, existe un mecanismo especial que utiliza la carpeta /DosDevices 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 nombre interno usando una capa de API debajo de la API de Win32 habitual; una buena herramienta para explorar el espacio de nombres del kernel es WinObj del grupo SysInternals en Microsoft.
Para obtener una descripción completa de las reglas que rodean los nombres legales de los 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 "¿por cuánto tiempo es el nombre de ruta legal más completo y calificado?".