Почему "Система не может найти указанную пакетную метку" выбрасывается, даже если метка существует?

Ответ 1

На самом деле вам нужно 2 условия:

• командный файл не должен использовать окончания строк CRLF
• метка, к которой вы переходите, должна охватывать границу блока (в отличие от и: метка конца, которая является просто ярлыком до конца вашего скрипта)

Видеть. Система не может найти указанную этикетку партии (с помощью и Пакетная обработка как можно!

Дэвид А. Грей упоминает в комментариях, видя (в Windows 10), что маршалответил в 2014 году (предположительно в Windows 7 или 8): сценарий/пакетная программа (.bat или .cmd), выполняемая без CALL, запускает преобразование eol.

За последние 35 лет я написал сотни пакетных сценариев, и единственная проблема, с которой у меня когда-либо возникали проблемы с отсутствием меток, была, когда разрывы строк файлов были преобразованы из Windows (CR/LF), которая работает, чтобы Unix (LF), чего нет.

Ответ 2

У меня такая же проблема. Однако основная причина не была CRLF. Это было потому, что в script я выполнил внешнюю программу, такую ​​как Ant, но не поставил CALL до Ant. Итак, убедитесь, что CALL каждая внешняя программа, используемая в вашей партии script.

Ответ 3

Вот проблема и как ее исправить. Проблема связана с ошибкой или функцией в пакетной CMOS-программе DOS. Сначала явная постановка задачи. Если у вас есть пакетный файл DOS с целевыми ярлыками типа ": dothis", а в конце метки у вас нет места, тогда командный файл не будет работать, если окончание строки будет окончанием строки UNIX. Это означает, что вам нужно запустить unix2dos в файле, прежде чем вы сможете его использовать.

Коренной причиной является процессор командной строки DOS, (программа оболочки), принимает символ конца строки UNIX как часть метки. Поскольку переход на часть никогда не использует это как метку, он никогда не встречается, поскольку такой ярлык действительно не существует. Решение состоит в том, чтобы разместить дополнительное пространство в конце каждой целевой метки или даже лучше каждой строки. Теперь конец строк UNIX не появляется, поскольку пространство действует как разделитель, и все это работает.

Ответ 4

Если пакетный файл имеет окончание строки Unix (разделители строк), это иногда может произойти.

Просто unix2dos это и проблема должна быть решена.

Ответ 5

Вы также должны убедиться, что при вызове других скриптов вы используете CALL вместо их вызова в среде вызывающего абонента.

Ответ 6

Я столкнулся с аналогичной проблемой только с .cmd файлом и Windows 8. Решение состояло в том, чтобы изменить все концы строк на стиль CR + LF DOS. Проблема была запутанной, потому что пакетный файл в основном работал и перестраивал линии, изменил эффект.

Файл .cmd выглядел так:

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...

Функция C вызовет ошибку "Система не может найти указанную пакетную метку". Как ни странно, это могло уйти, переставив вызовы. Изменение границ строк от 0x0A до 0x0D0A, похоже, исправило его.

Возможно, VonC означает "командный файл должен использовать окончания строки CRLF".

Ответ 7

У меня была эта проблема после копирования команды запуска из слова и вставки ее в окно команд. Был вариант с "-" спереди, и думал, что выглядит так же, как DOS "-" это было не так ". После ввода" - "сам вопрос был решен, и пакет работал... жесткий найти проблему....

Ответ 8

Немного другой вариант использования...

Я вызывал скрипт bat во время сборки Windows Server 2012 Server с использованием поставщика оболочки (OpenSSH). Теперь скрипт работал нормально с помощью cmd на подготовленной виртуальной машине (для остановки остановил сборку пакета и остановил ее, а затем подтвердил это)... но с этими метками вызовов не было обнаружено проблем.

Концы строк были в порядке, CRLF (подтверждено в Notepadd++). Скрипт работал нормально и через командную строку. Более того, иногда он просто используется для нормальной работы, а иногда и для сбоя, но если для какого-то ярлыка произошел сбой, то сбой был последовательным.

Первоначально я только начал полностью удалять подпрограммы, расширив сам вызов и поместив код подпрограммы в строку. Я сделал это для всех случаев, когда был только один вызов (без дублирования кода).

Но, да, я наткнулся на один саб, который был вызван из 3,4 мест. Перепробовав все, вот что у меня сработало

Добавление 8-10 операторов REM чуть выше подпрограммы. Да, я не шучу !!

PS: сценарий очень старый, но руководство нуждалось во мне, чтобы это работало через упаковщик (у нас есть план на второй день, чтобы заменить его на Ansible/Chef).