The system cannot find the batch label specified

[Steve Song]

From time to time I have encountered this cryptic error, and I could not
understand why the perfectly good script will generate this error, until
today.

It seems like the if the target label is spanning the batch processor's
buffer (blocksize=512, from my observation on Win2K & XP), the error message
is generated.

To test my theory, I have created simple batch file as following.
goto BROWSER
rem
#####################################################################################################################
rem
###########################################################################################################################
rem
###########################################################################################################################
rem
###########################################################################################################################
:BROWSER

If the :BROWSER spans buffer boundary, then batch processor will not find
the label and throw error.

It is hard to imagine that Microsoft has not encountered this issue
internally.
Fixing this issue will be extremely simple and it won't slow down the batch
processor that much. Microsoft should fix this error as there are quite a
few batch files out there with many goto and call statements.

 

[Pegasus \(MVP\)]

From time to time I have encountered this cryptic error, and I could not
understand why the perfectly good script will generate this error, until
today.

It seems like the if the target label is spanning the batch processor's
buffer (blocksize=512, from my observation on Win2K & XP), the error
message
is generated.

To test my theory, I have created simple batch file as following.
goto BROWSER
rem
#####################################################################################################################
rem
###########################################################################################################################
rem
###########################################################################################################################
rem
###########################################################################################################################
:BROWSER

If the :BROWSER spans buffer boundary, then batch processor will not find
the label and throw error.

It is hard to imagine that Microsoft has not encountered this issue
internally.
Fixing this issue will be extremely simple and it won't slow down the
batch
processor that much. Microsoft should fix this error as there are quite a
few batch files out there with many goto and call statements.

I think it is risky to conclude from a small number of observations
(perhaps just one single observation!) that there is a bug in a program.
Perhaps your testing platform is flawed? I tried your batch file and
made sure that the label spans the 512 byte boundary, by examining
its binary code. Here is what it looks like under debug.exe:

13A0:0250 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:0260 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:0270 23 23 23 23 23 23 23 23-23 0D 0A 72 65 6D 20 23 #########..rem
#
-d
13A0:0280 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:0290 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:02A0 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:02B0 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:02C0 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:02D0 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:02E0 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:02F0 23 23 23 23 23 23 23 23-23 23 0D 0A 3A 42 52 4F
##########..:BRO
-d
13A0:0300 57 53 45 52 0D 0A 64 69-72 20 63 3A 5C EE EE EE WSER..dir
c:\...
13A0:0310 EE EE EE EE EE EE EE EE-EE EE EE EE EE EE EE EE
.................
13A0:0320 EE EE EE EE EE EE EE EE-EE EE EE EE EE EE EE EE
.................

I then ran the batch file. It worked flawlessly.

If you still think that there is a bug then you should do some
rigorous testing, which involves testing your theory on different
machines. You should also report exactly how you invoke
your Command Processor. Running your machines in Safe Mode
is compulsory in order to eliminate any possible influence of
non-Microsoft code.

 

[Steve Song]

I think it is risky to conclude from a small number of observations
(perhaps just one single observation!) that there is a bug in a program.
Perhaps your testing platform is flawed? I tried your batch file and
made sure that the label spans the 512 byte boundary, by examining
its binary code. Here is what it looks like under debug.exe:

13A0:0250 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:0260 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:0270 23 23 23 23 23 23 23 23-23 0D 0A 72 65 6D 20 23 #########..rem
#
-d
13A0:0280 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:0290 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:02A0 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:02B0 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:02C0 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:02D0 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:02E0 23 23 23 23 23 23 23 23-23 23 23 23 23 23 23 23
################
13A0:02F0 23 23 23 23 23 23 23 23-23 23 0D 0A 3A 42 52 4F
##########..:BRO
-d
13A0:0300 57 53 45 52 0D 0A 64 69-72 20 63 3A 5C EE EE EE WSER..dir
c:\...
13A0:0310 EE EE EE EE EE EE EE EE-EE EE EE EE EE EE EE EE
.................
13A0:0320 EE EE EE EE EE EE EE EE-EE EE EE EE EE EE EE EE
.................

I then ran the batch file. It worked flawlessly.

If you still think that there is a bug then you should do some
rigorous testing, which involves testing your theory on different
machines. You should also report exactly how you invoke
your Command Processor. Running your machines in Safe Mode
is compulsory in order to eliminate any possible influence of
non-Microsoft code.

I must admit, that after I posted this message, I discovered the underlying
issue.
Thanks to a friend of mine who pointed out that once the file is converted
to dos format,
the script worked flawlessly. The original file was saved as Unix format
and I suspect
that fgets() or some related functions is used to parse the script.
A lessons learned from all this: If you ever get this error message and you
are certain the
label is there, then check for the file format.
Thanks again and sorry for the fuss.

 

[Pegasus \(MVP\)]

I must admit, that after I posted this message, I discovered the
underlying
issue.
Thanks to a friend of mine who pointed out that once the file is converted
to dos format,
the script worked flawlessly. The original file was saved as Unix format
and I suspect
that fgets() or some related functions is used to parse the script.
A lessons learned from all this: If you ever get this error message and
you
are certain the
label is there, then check for the file format.
Thanks again and sorry for the fuss.

I tend to disagree with your conclusion: If you think you have discovered
a bug, spend a lot of time exploring the issue in all possible ways before
demanding that "Microsoft should fix this error". There are a few million
installations of Windows out there and the chances that you have found
a real bug are very small. Drawing a conclusion from an observation on
a single machine is unsound.

 

[Steve Song]

I tend to disagree with your conclusion: If you think you have discovered
a bug, spend a lot of time exploring the issue in all possible ways before
demanding that "Microsoft should fix this error". There are a few million
installations of Windows out there and the chances that you have found
a real bug are very small. Drawing a conclusion from an observation on
a single machine is unsound.

Maybe I did not make myself clear in my previous reply. Yes I agee with you
that it is not a bug in the Microsoft's code. What I found was that if the
file
is saved in Unix format, one could encounter this issue. This issue is
likely to
be encountered for the forks like me who works in both Unix and Windows
platform.
It is not limiited to a single machine as you suggested. It has everything
to do with
file format. If you have any interest and would like to investigate any
deeper, simply
use tool such as Dos2Unix and Unix2Dos to convert CR/LF and CR. You can
easily
reproduce the issue in your own system. Instead of calling it a bug in the
batch processor,
I would calll it (1) warning for others - judging from the internet posting
a number of
people stumble into this issue and found other workarounds (2) Request for
enhancement
to support Unix fileformats -if fgets() can recognize \r as well \r\l as
line termination, this seemingly
strange issue could be resolved.
But I know better to hold my breadth for the enhancements to come any time
soon.

I hope some poor soul in the future can be saved from making the same
mistake by stumbling across this posting. That will be my redemption...

Again I am sorry for haste conclusion and false accusation.

[IT IS NOT A MS BUG, IT IS NOT A MS BUG, IT IS NOT A MS BUG...] My
punishment (-;

Good day,

 

[HeyBub]

I tend to disagree with your conclusion: If you think you have
discovered a bug, spend a lot of time exploring the issue in all
possible ways before demanding that "Microsoft should fix this
error". There are a few million installations of Windows out there
and the chances that you have found a real bug are very small. Drawing a
conclusion from an observation on
a single machine is unsound.

Uh, didn't he discover a but in MS's rendition of a Unix file?

 

[Pegasus \(MVP\)]

I would calll it (1) warning for others - judging from the internet

posting
a number of
people stumble into this issue and found other workarounds (2) Request for
enhancement
to support Unix fileformats -if fgets() can recognize \r as well \r\l as
line termination, this seemingly
strange issue could be resolved.
But I know better to hold my breadth for the enhancements to come any time
soon.

Right now (as we both know) a text file in Windows is defined
as a file containing ASCI or Unicode character strings that are
terminated with $0d$0a. While I have no doubt that it would be
possible to expand this definition to include strings terminated with
$0a, this would be a major enhancement requiring full regression
testing. I suspect that it would be a business decision for MS:
Whether to allocate resources for a feature that is used by a small
number of people who tend to be highly computer literate at a
nuts-and-bolts level. Let's face it: The vast majority of PC users
would not know what a CRLF is. Those who do have the knowledge
and the skills to manipulate EOL characters, either with a conversion
program (in your case) or a binary editor (in my case).

I recommend you stop holding your breath right now!