Erreur "La ligne d'entrée est trop longue" erreur dans le fichier BAT
J'ai un problème pour exécuter un fichier chauve-souris. Après un certain temps, l'erreur "La ligne d'entrée est trop longue" s'affiche.
La structure du fichier chauve-souris est simple. Il existe un fichier bat principal qui appelle 10 autres fichiers bat chargés de mettre à jour les données de mes modules système. Dans les fichiers de batte de données de mise à jour, il y a beaucoup d'appels à une commande (fichier .cmd) de mon système qui est responsable de la mise à jour des données à l'aide de certains calculs.
Le fait est que, lorsque le processus était en cours d'exécution sous Windows 2003 Server, tout était ok. Aucune erreur.
Ensuite, lorsqu’il a été mis à niveau vers Windows 2008 Server, j’exécute le fichier chauve-souris principal. Je ne peux même pas exécuter manuellement une commande incluse dans les chauves-souris de données mises à jour dans cette fenêtre cmd. Mais si je ferme la fenêtre cmd et en ouvre une nouvelle, je peux exécuter les commandes sans erreur.
Quelqu'un a eu le même problème? Ou une solution?
Merci d'avance.
J'ai eu le même problème lors de l'exécution d'un script de construction dans une fenêtre cmd. Après environ 13 fois, j'ai eu la même erreur. Le script de construction devait s'assurer que vcvarsall.bat était exécuté afin d'exécuter vcvarsall.bat à chaque fois.
vcvarsall.bat n’est pas assez intelligent pour ajouter des éléments à la variable path s’ils ne le sont pas déjà; un ensemble de doublons a donc été ajouté.
Ma solution a été d’ajouter une vérification si définie sur une variable d’environnement dont je sais qu’elle est définie par vcvarsall.bat ...
if not defined DevEnvDir (
call vcvarsall.bat
)
Vérifiez votre variable d'environnement de chemin après chaque exécution et voyez si elle augmente. Si c'est le cas et qu'il y a des doublons, vous devrez être intelligent pour ajouter des éléments à la variable path. Il y a plusieurs façons d'être intelligent à ce sujet.
Je suis tombé sur cette erreur pour la première fois juste après avoir exécuté le même jeu de commandes (arrêter/démarrer un serveur d'applications) plusieurs fois.
L'erreur s'est arrêtée lorsque j'ai ouvert une nouvelle ligne de commande et essayé les commandes à partir de la nouvelle console de ligne de commande.
Je réalise que c'est assez vieux, mais l'autre problème que j'ai rencontré était d'avoir un "" à la fin de la commande que j'appelais. J'essayais d'appeler
"C:\Fichiers de programme (x86)\Visual Studio 12.0\Common7\Tools ..\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" "
Si vous remarquez, j’en ai deux "à la fin de la ligne. C’est ce qui me causait des problèmes (Notepad ++ l’a inclus lorsque je tapais les guillemets). à la recherche d'informations et rien d'autre ne fonctionne, vérifiez ceci: :)
Il existe un article de la base de connaissances Windows sur ce sujet. Ils ne mentionnent pas le serveur Windows 2008, mais ils ont mentionné la différence de taille entre les autres versions du système d'exploitation. Par conséquent, il ne serait pas étonnant qu'il existe une différence entre 2003 et 2008.
En ce qui concerne les solutions au problème, certaines de leurs suggestions incluent:
- Modifiez les programmes nécessitant de longues lignes de commande afin qu'ils utilisent un fichier contenant les informations de paramètre, puis incluez le nom du fichier dans la ligne de commande.
- Utilisez des noms plus courts pour les dossiers et les fichiers.
- Réduisez la profondeur des arborescences de dossiers.
Vous pouvez lire l'intégralité de l'article si vous voulez voir ce qu'ils ont à dire, mais c'étaient les suggestions les plus susceptibles de s'appliquer à vous.
Cela peut aussi arriver si les espaces de votre fichier (caractère Ansi 0x20) sont vraiment des espaces insécables (j'avais 0xA0 , mais le vôtre peut varier) Cela peut arriver si vous copiez/collez depuis Internet vers un éditeur prenant en charge UTF-8.
Le résultat dépend de la page de codes actuelle de Windows, de votre éditeur, etc. Pour réparer:
- Utiliser un éditeur hexadécimal
- Regardez comment les espaces sont représentés
- Rechercher et remplacer votre représentation
J'ai utilisé HxD pour rechercher et remplacer 0xA0 par 0x20.
J'ai couru dans cela aussi.
J'essayais de lancer vcvars.bat comme d'autres ici.
Le problème sous-jacent pour moi semblait être que ma variable PATH était polluée par des répétitions d'un chemin déjà assez long. Réparer mon chemin semblait résoudre le problème pour moi (dans un nouveau terminal, bien sûr). Notez que ce correctif n'est pas spécifique à vcvars.bat ou à tout élément lié à Visual Studio.
Je suis curieux de savoir si la solution de Cookie Butter est une solution de contournement et que le problème sous-jacent est le même.