Estoy intentando obtener la salida al ejecutar programas externos a través de cli en el comando de Windows. Así que usé el nodo Execute Command para ejecutar los comandos, pero siempre me devuelve un stdout vacío. En la versión 1.xx podría ver la salida stdout, pero con la versión 2.xx ya no la veo. También intenté redirigir la salida a un archivo txt, pero el archivo txt seguiría estando vacío. Ejecutar el comando localmente funciona, pero ejecutarlo dentro de n8n no me devuelve salida stdout.
¿Cuál es el mensaje de error (si existe)?
Por favor comparte tu flujo de trabajo
Comparte la salida devuelta por el último nodo
Información sobre tu configuración de n8n
versión de n8n: 2.29.9
Base de datos (predeterminada: SQLite): predeterminada
configuración de EXECUTIONS_PROCESS de n8n (predeterminada: own, main): predeterminada
Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio): npm
Para verificar que stdout realmente está funcionando, elimina las redirecciones de archivos y el comando cd. Usa la ruta absoluta al ejecutable. Esto elimina la posibilidad de que cd falle o de que la salida se oculte en un archivo.
Si el comando anterior sigue devolviendo stdout vacío, el error probablemente esté oculto en stderr. Puedes forzar a Windows a fusionar la secuencia de errores en la secuencia de salida agregando 21 al final de tu comando.
Ya que estás ejecutando en Windows Server 2022, verifica qué usuario está ejecutando el proceso n8n.
Si n8n se ejecuta como un Servicio o bajo un usuario diferente a “Administrator”, no tendrá permiso para escribir en C:\Users\Administrator\Desktop\....
Solución: Mueve tus herramientas y carpetas de salida a un directorio de nivel raíz como C:\n8n-tools\ y otorga “Control Total” al grupo Everyone o al usuario específico que ejecuta n8n.
Intenté ambos comandos y aún devuelven salida vacía. No hay otros usuarios en este servidor y n8n no se ejecuta como servicio. Intenté mover las herramientas a un nivel raíz y aún así da salida vacía
no funciona usando 2x comillas dobles no será reconocido como un comando
'""C:\MediaInfo_CLI_26.05_Windows_x64\MediaInfo.exe" "test.mkv""' is not recognized as an internal or external command, operable program or batch file.
"C:\MediaInfo_CLI_26.05_Windows_x64\MediaInfo.exe" "C:\Users\Administrator\Desktop\Anime\Upload\[Gecko] Muzik Tiger In the Forest [2025, TVER.WEB-DL 1080P]\[Gecko] Muzik Tiger In the Forest - S01E01 [TVER.WEB-DL 1080P AVC, AAC][D41B8A37].mkv"
Si la salida sigue vacía, significa que MediaInfo se está bloqueando antes de poder imprimir nada. Para ver el informe de bloqueo “oculto”, añade 2>&1 al final. Esto fuerza que los errores aparezcan en la salida:
"C:\MediaInfo_CLI_26.05_Windows_x64\MediaInfo.exe" "C:\Users\Administrator\Desktop\Anime\Upload\[Gecko] Muzik Tiger In the Forest [2025, TVER.WEB-DL 1080P]\[Gecko] Muzik Tiger In the Forest - S01E01 [TVER.WEB-DL 1080P AVC, AAC][D41B8A37].mkv" 2>&1
Como ya estás en la compilación de CLI e incluso la redirección de archivos sale vacía, el comando definitivamente está ejecutándose — MediaInfo en sí no está produciendo nada. Hay dos cosas que aún no se han verificado en este hilo:
1. Mira el campo exitCode en la salida del nodo Execute Command (se devuelve junto con stdout/stderr). Ese único número divide el problema por la mitad: 0 significa que MediaInfo se ejecutó “correctamente” y realmente no imprimió nada, un valor distinto de cero significa que está fallando antes de producir salida.
2. Tu archivo de prueba se encuentra en C:\Users\Administrator\Desktop. Esto explicaría la diferencia entre 1.x y 2.x: si tu n8n 2.x se inicia de manera diferente a como se iniciaba 1.x (cuenta de usuario diferente, un servicio, una tarea programada, una sesión de terminal diferente), el proceso simplemente podría no ser capaz de leer la carpeta Desktop de otra cuenta — y MediaInfo es silencioso sobre archivos de entrada ilegibles. Prueba rápida: copia el video en C:\n8n-tools\ (que ya sabes que n8n puede alcanzar, ya que dir funcionó allí) y ejecuta MediaInfo en esa copia.
Y una prueba de aislamiento de 30 segundos que no necesita ningún archivo de entrada:
ejecutada dentro del nodo Execute Command. Si la cadena de versión regresa, el binario y la tubería de stdout están bien y el problema es el acceso al archivo de entrada (punto 2). Si incluso --Version está vacío dentro de n8n mientras imprime en tu propia ventana cmd, entonces es el contexto de proceso en el que se ejecuta n8n, no el archivo.
Una salida de emergencia más que vale la pena conocer: MediaInfo puede escribir su informe directamente en un archivo, omitiendo stdout por completo:
Si report.json obtiene contenido mientras stdout permanece vacío, lo has aislado a la captura de stdout; si también está vacío, MediaInfo nunca leyó el archivo. (--Output=JSON también te ahorra analizar el diseño de texto más adelante.)
El código de salida es 0 mientras que stdout está vacío. No sabía que Mediainfo tuviera una función de registro integrada y que hiciera exactamente lo que quería guardando la salida en un archivo. Básicamente "C:\MediaInfo_CLI_26.05_Windows_x64\MediaInfo.exe" --Output=JSON --LogFile=C:\n8n-tools\report.json "C:\n8n-tools\your_video.mkv" hizo el trabajo, solo que stdout seguía vacío pero mientras guardara en un archivo json que pueda analizar posteriormente, está bien.
¡Me alegra que la ruta --LogFile te haya desbloqueado, y gracias por cerrar el bucle con los resultados exactos — “exitCode 0 pero stdout aún vacío” es un detalle de oro para la próxima persona que llegue aquí. Como echo y dir funcionan pero un .exe externo sigue sin generar salida incluso en caso de éxito, esto parece ser un cambio en la versión 2.x en cómo Execute Command captura la salida de procesos secundarios en Windows — podría valer la pena presentarlo como un informe de error para que se corrija en el origen. ¡Que disfrutes automatizando!