I\'m having a problem with a Windows batch file and labels. I keep getting this error:
The system cannot find the batch label
One possibility, although it seems unlikely, is that command extensions aren't enabled, or up-to-date, and this is interfering with call/goto/label behaviour.
Try:
echo [%cmdextversion%]
and if it's less than [2]
(or empty -- []
) then check to see if cmd.exe
is being invoked with /e:off
, or just run
cmd /e:on
in the console window where you will run this batch file.
Looking closely at your hex, it does not actually have all CRLF (0d 0a
). Several lines end in LF-only (0a
without a preceding 0d
).
Check in your hex editor to make sure every 0a
is preceded by 0d
(exactly one).
Or just cut and paste your file into a blank Notepad document and re-save it.
Are you using Windows NT 4/Windows 2000? Only there can you use CALL to call subroutines within the same batch file.
the moral of the story: when calling external programs/batch files in a batch file, use call
call foo.bat
and/or
call %foo%
(Calling one batch from another has been done since the days of DOS, just remember to call)
I would point out that the "Testing 1.2.3..." and "Press any key to continue . . ." lines indicate that execution has successfully gone to the :dozip label and then successfully returned to the caller.
Is the "7za" executable actually a batch file? If I modify my test script to have the helper be a batch file, I get the same error. The fix is to do 'call %zip% %1'
The "The system cannot find the batch label specified" error message brought me here (10 years later!) and the problem turned out to be the CRLF was incorrect.
The cause, in our case, was a Git Repository that didn't recognize BAT files as being text files which needed to be CRLF on a Windows 7 machine.
Our solution was to create a .gitattributes file containing the line:
*.bat text eol=crlf
Then deleting the BAT files and checking out from the repository re-wrote our BAT files with the correct line endings. The BAT labels are now working again.