Pourquoi "Le système ne trouve pas l'étiquette de lot spécifiée" est lancé même si l'étiquette existe?
Lors de l'exécution d'un fichier de commandes dans Windows XP J'ai trouvé un message d'erreur aléatoire:
Le système ne peut pas trouver l'étiquette de lot spécifiée name_of_label
Bien sûr, l'étiquette existait. Qu'est-ce qui cause cette erreur?
En fait, vous avez besoin de 2 conditions pour que cela se produise:
- le fichier batch ne doit pas utiliser de fins de ligne CRLF
- l'étiquette vers laquelle vous accédez doit s'étendre sur une limite de bloc (par opposition à et: étiquette de fin qui n'est qu'un raccourci vers la fin de votre script)
Voir. Le système ne peut pas trouver l'étiquette de lot spécifiée (par et Batch-as-batch-can!
David A. Gray mentionne dans les commentaires voir (sur Windows 10) ce que Marshalréponse a montré en 2014 (vraisemblablement sous Windows 7 ou 8): un programme de script/batch (.bat ou .cmd) exécuté sans CALL déclencherait une conversion eol.
J'ai écrit des centaines de scripts de commandes au cours des 35 dernières années, et la seule fois où j'ai eu un problème avec des étiquettes non trouvées était lorsque les sauts de ligne du fichier étaient convertis de Windows (CR/LF), ce qui fonctionne, en Unix (LF), qui ne fonctionne pas.
J'ai déjà eu le même problème. Cependant, la cause profonde n'était pas du tout CRLF. C'est parce que dans le script, j'ai exécuté un programme externe tel que Ant, mais je n'ai pas mis un CALL avant Ant. Donc, assurez-vous de CALL chaque programme externe utilisé dans votre script batch.
Voici le problème et comment le résoudre. Le problème est un bogue ou une fonctionnalité du programme DOS batch cmd. D'abord l'énoncé clair du problème. Si vous avez un fichier batch DOS avec des étiquettes cibles comme ": dothis", et à la fin de l'étiquette vous n'avez pas d'espace, alors le fichier batch ne fonctionnera pas si la fin de ligne est une fin de ligne UNIX. Cela signifie que vous devez exécuter unix2dos sur le fichier avant de pouvoir l'utiliser.
La cause principale est que le processeur de ligne de commande DOS (programme Shell) prend le caractère de fin de ligne UNIX dans le cadre de l'étiquette. Étant donné que le passage à la partie ne l'utilise jamais comme étiquette, il n'est jamais trouvé car une telle étiquette n'existe vraiment pas. La solution est de mettre un espace supplémentaire à la fin de chaque étiquette cible, voire mieux chaque ligne. Maintenant, la fin des lignes UNIX ne vient pas jouer car l'espace agit comme le séparateur et tout fonctionne.
Si le fichier batch a des fins de ligne Unix (séparateurs de ligne), cela peut parfois arriver.
Juste nix2dos et le problème devrait être résolu.
Vous devez également vous assurer que lorsque vous appelez d'autres scripts, vous utilisez CALL, au lieu de les appeler dans l'environnement de l'appelant.
J'ai rencontré un problème similaire tout à l'heure avec un fichier .cmd et Windows 8. La solution était de changer toutes les fins de ligne en style DOS CR + LF. Le problème était déroutant car le fichier de commandes fonctionnait principalement et la réorganisation des lignes changeait l'effet.
Le fichier .cmd ressemblait à:
call:function_A "..\..\folderA\"
call:function_B "..\..\folderB\"
call:function_C "..\..\folderC\"
call:function_D "..\..\folderD\"
goto:eof
:function_A
rem do stuff
goto:eof
...etc...
La fonction C provoquerait l'erreur "Le système ne peut pas trouver l'étiquette de lot spécifiée". Étrangement, cela pourrait disparaître en réorganisant les appels. Changer les fins de ligne de 0x0A à 0x0D0A semble l'avoir corrigé.
VonC signifiait peut-être "le fichier de commandes doit utiliser les fins de ligne CRLF".
j'ai eu ce problème après avoir copié une commande de démarrage à partir de Word et le coller dans la fenêtre de commande. Il y avait une option avec "-" à l'avant, et pensait que le même aspect que le DOS "-" ce n'était pas :) Après avoir tapé le "-" par moi-même, le problème a été résolu et le lot a fonctionné ... un disque pour trouver un problème ....
Petit cas d'utilisation différent ...
J'appelais un script bat pendant packer build de Windows Server 2012 Server, en utilisant le Shell provisioner (OpenSSH). Maintenant, le script fonctionnait bien via cmd dans la machine virtuelle provisionnée (mettre le point d'arrêt dans la construction du packer pour l'arrêter et le confirmer) ... mais, il échouait avec ces problèmes d'appels d'étiquette d'appel non trouvés.
Les fins de ligne étaient correctes, CRLF (confirmé dans Notepadd ++). Le script fonctionnait également très bien via la ligne de commande. De plus, parfois, il suffit de fonctionner correctement et parfois d'échouer, mais une fois échoué pour une étiquette, l'échec était cohérent.
Au début, je viens de commencer à supprimer complètement les sous-programmes en développant l'appel lui-même et en mettant le code des sous-programmes en ligne. Je l'ai fait pour tous les cas où il n'y avait qu'un seul appel (pas de duplication de code).
Mais, oui, je suis tombé sur un sous-marin qui a été appelé à 3,4 endroits. Après avoir tout essayé, c'est ce qui a fonctionné pour moi
Ajout de 8 à 10 REM juste au-dessus du sous-programme. Oui, je ne plaisante pas !!
PS: Le script est très très ancien, mais la direction avait besoin de moi pour que cela fonctionne via packer (nous avons un plan de ce jour-là pour le remplacer par Ansible/Chef).