J’essaie d’obtenir la sortie lors de l’exécution de n’importe quel programme externe via CLI dans Windows Command. J’ai donc utilisé le nœud Execute Command pour exécuter les commandes, mais il me donne toujours un stdout vide. Dans la version 1.xx, je pouvais voir la sortie stdout, mais avec la version 2.xx, je ne les vois plus. J’ai aussi essayé de rediriger la sortie vers un fichier txt, mais le fichier txt serait toujours vide à l’intérieur. L’exécution de la commande localement fonctionne, mais l’exécution à l’intérieur de n8n ne donne pas de sortie stdout
Quel est le message d’erreur (le cas échéant) ?
Veuillez partager votre workflow
Partagez la sortie retournée par le dernier nœud
Informations sur votre configuration n8n
Version n8n : 2.29.9
Base de données (par défaut : SQLite) : par défaut
Pour vérifier que stdout fonctionne réellement, supprimez les redirections de fichiers et la commande cd. Utilisez le chemin absolu vers l’exécutable. Cela élimine la possibilité que cd échoue ou que la sortie soit cachée dans un fichier.
Si la commande ci-dessus retourne toujours une stdout vide, l’erreur est probablement cachée dans stderr. Vous pouvez forcer Windows à fusionner le flux d’erreur dans le flux de sortie en ajoutant 2> &1 à la fin de votre commande.
Puisque vous exécutez sur Windows Server 2022, vérifiez quel utilisateur exécute le processus n8n.
Si n8n s’exécute en tant que Service ou sous un utilisateur différent d’« Administrator », il n’aura pas la permission d’écrire dans C:\Users\Administrator\Desktop\....
Solution : Déplacez vos outils et dossiers de sortie vers un répertoire au niveau racine comme C:\n8n-tools\ et accordez « Contrôle total » au groupe « Tous » ou à l’utilisateur spécifique exécutant n8n.
J’ai essayé les deux commandes et j’obtiens toujours une sortie vide. Il n’y a pas d’autres utilisateurs sur ce serveur et n8n ne fonctionne pas en tant que service. J’ai essayé de déplacer les outils au niveau racine et cela donne toujours une sortie vide
ne fonctionne pas avec 2x guillemets doubles ne sera pas reconnu comme une commande
'""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 sortie est toujours vide, cela signifie que MediaInfo s’arrête avant de pouvoir imprimer quoi que ce soit. Pour voir le rapport de crash « caché », ajoutez 2>&1 à la fin. Cela force les erreurs à s’afficher dans la sortie :
"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
Puisque vous êtes déjà sur la version CLI et même la redirection de fichier ne produit rien, la commande s’exécute définitivement — MediaInfo lui-même ne produit rien. Deux choses qui n’ont pas encore été vérifiées dans ce fil :
1. Regardez le champ exitCode dans la sortie du nœud Execute Command (il est renvoyé avec stdout/stderr). Ce seul nombre divise le problème en deux : 0 signifie que MediaInfo s’est exécuté « avec succès » et n’a vraiment rien imprimé, une valeur non-nulle signifie qu’il échoue avant de produire une sortie.
2. Votre fichier de test se trouve sur C:\Users\Administrator\Desktop. Cela expliquerait la différence 1.x → 2.x : si votre n8n 2.x est démarré différemment de la façon dont 1.x l’était (compte utilisateur différent, un service, une tâche planifiée, une session de terminal différente), le processus peut simplement ne pas pouvoir lire le dossier Desktop d’un autre compte — et MediaInfo est silencieux sur les fichiers d’entrée illisibles. Test rapide : copiez la vidéo dans C:\n8n-tools\ (que vous savez déjà que n8n peut atteindre, puisque dir a fonctionné là) et exécutez MediaInfo contre cette copie.
Et un test d’isolation de 30 secondes qui ne nécessite aucun fichier d’entrée :
exécutez à l’intérieur du nœud Execute Command. Si la chaîne de version revient, le binaire et la plomberie stdout sont corrects et le problème est l’accès au fichier d’entrée (point 2). Si même --Version est vide à l’intérieur de n8n alors qu’il s’affiche dans votre propre fenêtre cmd, c’est le contexte de processus sous lequel n8n s’exécute, pas le fichier.
Une autre échappatoire worth knowing : MediaInfo peut écrire son rapport directement dans un fichier lui-même, en contournant complètement stdout :
Si report.json obtient du contenu alors que stdout reste vide, vous l’avez isolé à la capture de stdout ; s’il est vide aussi, MediaInfo n’a jamais lu le fichier. (--Output=JSON vous épargne aussi l’analyse de la disposition du texte plus tard.)
Le code de sortie est 0 tandis que stdout est vide. Je ne savais pas que Mediainfo avait une fonction de journalisation intégrée et que cela faisait exactement ce que je voulais en sauvegardant la sortie dans un fichier. À peu près "C:\MediaInfo_CLI_26.05_Windows_x64\MediaInfo.exe" --Output=JSON --LogFile=C:\n8n-tools\report.json "C:\n8n-tools\your_video.mkv" a fait le travail, stdout était toujours vide mais du moment qu’il était sauvegardé dans un fichier JSON, je pouvais le parser plus tard.
Ravi que l’option --LogFile t’ait débloqué la situation, et merci d’avoir fermé la boucle avec les résultats exacts — « exitCode 0 but stdout still empty » est un détail en or pour la prochaine personne qui atterrira ici. Puisque echo et dir fonctionnent mais qu’un fichier .exe externe reste silencieux même en cas de succès, cela ressemble bien à un changement en version 2.x dans la façon dont Execute Command capture la sortie des processus enfants sous Windows — ça vaudrait peut-être le coup de signaler un bug pour que ça soit corrigé en amont. Bon automatisation !