레이블이있는 경우에도 "시스템에서 지정된 배치 레이블을 찾을 수 없습니다"가 발생하는 이유는 무엇입니까?

레이블이있는 경우에도 "시스템에서 지정된 배치 레이블을 찾을 수 없습니다"가 발생하는 이유는 무엇입니까?

---

Windows XP에서 배치 파일을 실행하는 동안 무작위로 발생하는 오류 메시지를 발견했습니다.

시스템이 지정된 name_of_label 배치 레이블을 찾을 수 없습니다.

물론 라벨이 존재했습니다. 이 오류의 원인은 무엇입니까?

---

실제로이를 위해서는 두 가지 조건이 필요합니다.

• 배치 파일은 CRLF 줄 끝을 사용하지 않아야합니다.
• 점프하는 레이블은 블록 경계에 걸쳐 있어야합니다 (및 : end 레이블과는 반대로 스크립트 끝의 바로 가기)

보다. 시스템이 지정된 배치 레이블을 찾을 수 없습니다 (by 및 Batch-as-batch-can!

David A. Gray 는 2014 년 (아마도 Windows 7 또는 8에서) Marshal 의 답변이 보여준 댓글 (Windows 10에서)에 대해 언급 했습니다 . 스크립트 / 배치 프로그램 ( 또는 )이없이 실행되면 eol 변환이 트리거됩니다..bat.cmdCALL

지난 35 년 동안 수백 개의 배치 스크립트를 작성했으며 레이블을 찾을 수없는 문제가 발생한 유일한 시간은 파일의 줄 바꿈이 Windows (CR / LF)에서 다음으로 변환되었을 때였습니다. 유닉스 (LF)는 그렇지 않습니다.

---

나는 전에 같은 문제가 있습니다. 그러나 근본 원인은 전혀 CRLF가 아닙니다. 스크립트에서 Ant와 같은 외부 프로그램을 실행했지만 CALLAnt 앞에는 넣지 않았기 때문 입니다. 따라서 CALL배치 스크립트에 사용 된 모든 외부 프로그램 을 확인하십시오 .

---

다음은 문제와 해결 방법입니다. 문제는 DOS 배치 cmd 프로그램의 버그 또는 기능입니다. 먼저 명확한 문제 진술. ": dothis"와 같은 대상 레이블이있는 DOS 배치 파일이 있고 레이블 끝에 공백이없는 경우 행 끝이 UNIX 행 끝이면 배치 파일이 작동하지 않습니다. 즉, 파일을 사용하기 전에 unix2dos를 실행해야합니다.

근본 원인은 DOS 명령 행 처리기 (쉘 프로그램)이며, 레이블의 일부로 UNIX 행 끝 문자를 사용합니다. go to part는 이것을 레이블로 사용하지 않기 때문에 그러한 레이블이 실제로 존재하지 않기 때문에 결코 찾을 수 없습니다. 해결책은 각 대상 레이블의 끝에 추가 공간을 두거나 모든 줄에 더 좋습니다. 이제 UNIX 줄 끝은 공백이 구분 기호 역할을하고 모두 작동하기 때문에 재생되지 않습니다.

---

배치 파일에 유닉스 줄 끝 (줄 구분 기호)이있는 경우이 문제가 때때로 발생할 수 있습니다.

그냥 unix2dos 하고 문제가 해결되어야합니다.

---

또한 다른 스크립트를 호출 할 때 호출자의 환경에서 호출하는 대신 CALL을 사용하는지 확인해야합니다.

---

방금 .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 줄 끝을 사용해야 함"을 의미했을 것입니다.

---

단어에서 시작 명령을 복사하여 명령 창에 붙여 넣은 후이 문제가 발생했습니다. 앞에 "-"가있는 옵션이 있었고 DOS "-"와 똑같다고 생각했습니다. :) 혼자서 "-"를 입력 한 후 문제가 해결되고 배치가 작동했습니다. 문제를 찾기 위해 ....

---

약간 다른 사용 사례 ...

셸 프로비저닝 도구 (OpenSSH)를 사용하여 Windows Server 2012 Server의 패커 빌드 중에 bat 스크립트를 호출했습니다 . 이제 스크립트는 프로비저닝 된 가상 머신에서 cmd를 통해 제대로 작동했습니다 (패커 빌드에 중단 점을 넣어이를 중지하고 확인) ...하지만 이러한 호출 레이블에서 문제를 찾을 수 없어서 실패했습니다.

The Line Endings were fine, CRLF (confirmed in Notepadd++). The script was working fine through command line as well. What more, sometimes, it just use to run fine and sometime fail, but once failed for some label, the failure was consistent.

Initially, I just started removing the subroutines altogether by expanding the call itself and putting subroutine code inline. I did this for all instances where there was only one call (no code duplication).

But, yeah, i did stumble upon one sub which was called from 3,4 places. After trying everything, this is what worked for me

Adding 8-10 REM statements just above the subroutine. Yes, I am not kidding !!

PS : The script is very very old, but management needed me to make that work through packer (we have a Day-2 plan of this to replace it with Ansible/Chef).

ReferenceURL : https://stackoverflow.com/questions/232651/why-the-system-cannot-find-the-batch-label-specified-is-thrown-even-if-label-e