Estou tentando obter a saída ao executar qualquer programa externo via CLI no comando Windows. Então usei o nó Execute Command para executar os comandos, mas ele sempre me dá stdout vazio. Na versão 1.xx eu conseguia ver a saída do stdout, mas na versão 2.xx não consigo mais vê-la. Também tentei redirecionar a saída para um arquivo txt, mas o arquivo txt ainda estaria vazio. Executar o comando localmente funciona, mas executá-lo dentro do n8n não fornece saída de stdout
Qual é a mensagem de erro (se houver)?
Por favor, compartilhe seu workflow
Compartilhe a saída retornada pelo último nó
Informações sobre sua configuração de n8n
Versão do n8n: 2.29.9
Banco de dados (padrão: SQLite): padrão
Configuração EXECUTIONS_PROCESS do n8n (padrão: own, main): padrão
Executando n8n via (Docker, npm, n8n cloud, app desktop): npm
Para verificar se stdout está realmente funcionando, remova os redirecionamentos de arquivo e o comando cd. Use o caminho absoluto para o executável. Isso elimina a possibilidade de cd falhar ou da saída estar oculta em um arquivo.
Se o comando acima ainda retornar stdout vazio, o erro provavelmente está oculto em stderr. Você pode forçar o Windows a mesclar o fluxo de erro no fluxo de saída adicionando 2 1 ao final do seu comando.
Como você está executando no Windows Server 2022, verifique qual usuário está executando o processo n8n.
Se o n8n está sendo executado como um Serviço ou sob um usuário diferente de “Administrator”, ele não terá permissão para escrever em C:\Users\Administrator\Desktop\....
Solução: Mova suas ferramentas e pastas de saída para um diretório no nível raiz como C:\n8n-tools\ e conceda “Controle Total” ao grupo Everyone ou ao usuário específico que executa o n8n.
Tentei ambos os comandos e ainda retorno saída vazia. Não há outros usuários neste servidor e n8n não está sendo executado como um serviço. Tentei mover as ferramentas para o nível raiz e ainda assim retorna saída vazia
não funciona com 2x aspas duplas não será reconhecido como um 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"
Se a saída ainda estiver vazia, significa que o MediaInfo está travando antes de conseguir exibir qualquer coisa. Para ver o relatório de erro “oculto”, adicione 2>&1 no final. Isso força os erros aparecerem na saída:
"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 você já está no build CLI e mesmo o redirecionamento de arquivo sai vazio, o comando definitivamente está sendo executado — o próprio MediaInfo não está produzindo nada. Duas coisas que ainda não foram verificadas nesta thread:
1. Olhe o campo exitCode na saída do nó Execute Command (é retornado junto com stdout/stderr). Esse único número divide o problema pela metade: 0 significa que MediaInfo rodou “com sucesso” e genuinamente não imprimiu nada, um valor diferente de zero significa que está falhando antes de produzir saída.
2. Seu arquivo de teste está em C:\Users\Administrator\Desktop. Isso explicaria a diferença 1.x → 2.x: se seu n8n 2.x é iniciado diferentemente de como o 1.x era (conta de usuário diferente, um serviço, uma tarefa agendada, uma sessão de terminal diferente), o processo pode simplesmente não conseguir ler a pasta Desktop de outra conta — e MediaInfo é silencioso sobre arquivos de entrada ilegíveis. Teste rápido: copie o vídeo para C:\n8n-tools\ (que você já sabe que n8n consegue acessar, já que dir funcionou lá) e execute MediaInfo contra essa cópia.
E um teste de isolamento de 30 segundos que não precisa de arquivo de entrada algum:
execute dentro do nó Execute Command. Se a string de versão voltar, o binário e a tubulação stdout estão bem e o problema é acesso ao arquivo de entrada (ponto 2). Se até mesmo --Version está vazio dentro do n8n enquanto imprime na sua própria janela cmd, então é o contexto do processo em que n8n roda, não o arquivo.
Uma saída de emergência a mais para conhecer: MediaInfo pode escrever seu relatório diretamente em um arquivo ele mesmo, contornando stdout completamente:
Se report.json receber conteúdo enquanto stdout fica vazio, você isolou para captura de stdout; se também estiver vazio, MediaInfo nunca leu o arquivo. (--Output=JSON também o poupa de fazer parsing do layout de texto depois.)
O código de saída é 0 enquanto stdout está vazio. Não sabia que o Mediainfo tinha um recurso de logging integrado e que fazia exatamente o que eu queria, salvando a saída em um arquivo. Basicamente "C:\MediaInfo_CLI_26.05_Windows_x64\MediaInfo.exe" --Output=JSON --LogFile=C:\n8n-tools\report.json "C:\n8n-tools\your_video.mkv" fez o trabalho, apenas stdout continuou vazio, mas desde que salvasse em um arquivo JSON que eu pudesse analisar depois, tudo bem.
Fico feliz que a rota --LogFile te desbloqueou, e obrigado por fechar o loop com os resultados exatos — “exitCode 0 mas stdout ainda vazio” é um detalhe ouro para a próxima pessoa que chegar aqui. Como echo e dir funcionam, mas um .exe externo fica silencioso mesmo com sucesso, isso realmente parece ser uma mudança na versão 2.x de como Execute Command captura a saída de processos filhos no Windows — pode valer a pena registrar isso como um relatório de bug para que seja corrigido upstream. Ótima automação!