markar100
asked on
Batch files: comments in multi-line blocks
This isn't so much of a question as a notation of odd behavior. I have always assumed that the batch interpreter interprets multi-line blocks as a single line as follows:
if [%1]==[] (
echo No parameters!
goto :EOF
)
gets interpreted as
if [%1]==[] ( echo No parameters! & goto :EOF)
For this reason, comments in a multi-line block would be a problem:
if [%1]==[] (
rem Handle incorrect call
echo No parameters!
goto :EOF
)
becomes
if [%1]==[] ( rem Handle incorrect call & echo No parameters! & goto :EOF)
which obviously causes the commands after the comment to be treated as a comment. I am pretty sure that this was how things worked in WinNT.
However, this no longer seems to be the case in WinXP, so I have started commenting like I would in any programming language (copiously, that is). So far so good. I use the :: for comments instead of rem because it looks better and because it is a little more efficient, since the processor doesn't have to interpret the line. So now we have
if [%1]==[] (
::Handle incorrect call
echo No parameters!
goto :EOF
)
Everything still works, although if you leave echo on, you can see that the batch processor doesn't even acknowledge the existence of the comment (unlike REMed comments). The problem came up when I happened to put two comments in a row within a multi-line block.
if [%1]==[] (
::Handle incorrect call
::Tell the user, then quit
echo No parameters!
goto :EOF
)
Now I get an obscure message that says
The system cannot find the drive specified.
The batch file still executes correctly, I just see this error message whenever there are two :: comments in a row. Replacing either :: with rem fixes the problem. Placing a command between the comments fixes the problem. Placing an empty line between the comments causes an incorrect syntax error which stops the whole batch file.
This problem is easy enough to work around, and might be commonly known, although I couldn't find any previous questions about it. I guess I'm just posting this as a warning, since it took me an hour or so to figure out what was causing the problem (it was in the middle of a moderately complex batch file). It takes quite a while before you start to think about your comments as a possible cause of a problem, and even then, it took a while before I realized it wasn't the particular text in the comments.
I am curious as to what the batch interpreter is seeing when I do this. If anyone can shed some light on the issue, I would be interested.
Thanks,
Mark
if [%1]==[] (
echo No parameters!
goto :EOF
)
gets interpreted as
if [%1]==[] ( echo No parameters! & goto :EOF)
For this reason, comments in a multi-line block would be a problem:
if [%1]==[] (
rem Handle incorrect call
echo No parameters!
goto :EOF
)
becomes
if [%1]==[] ( rem Handle incorrect call & echo No parameters! & goto :EOF)
which obviously causes the commands after the comment to be treated as a comment. I am pretty sure that this was how things worked in WinNT.
However, this no longer seems to be the case in WinXP, so I have started commenting like I would in any programming language (copiously, that is). So far so good. I use the :: for comments instead of rem because it looks better and because it is a little more efficient, since the processor doesn't have to interpret the line. So now we have
if [%1]==[] (
::Handle incorrect call
echo No parameters!
goto :EOF
)
Everything still works, although if you leave echo on, you can see that the batch processor doesn't even acknowledge the existence of the comment (unlike REMed comments). The problem came up when I happened to put two comments in a row within a multi-line block.
if [%1]==[] (
::Handle incorrect call
::Tell the user, then quit
echo No parameters!
goto :EOF
)
Now I get an obscure message that says
The system cannot find the drive specified.
The batch file still executes correctly, I just see this error message whenever there are two :: comments in a row. Replacing either :: with rem fixes the problem. Placing a command between the comments fixes the problem. Placing an empty line between the comments causes an incorrect syntax error which stops the whole batch file.
This problem is easy enough to work around, and might be commonly known, although I couldn't find any previous questions about it. I guess I'm just posting this as a warning, since it took me an hour or so to figure out what was causing the problem (it was in the middle of a moderately complex batch file). It takes quite a while before you start to think about your comments as a possible cause of a problem, and even then, it took a while before I realized it wasn't the particular text in the comments.
I am curious as to what the batch interpreter is seeing when I do this. If anyone can shed some light on the issue, I would be interested.
Thanks,
Mark
sirbounty
Interesting info - thanx for sharing...I believe we have a couple of die-hard DOS gurus here that might be able to shed some light on this...if you don't mind, I'll sit back and watch. :D
I don't use the :: as comments, but I've seen them used before.
As for how the command interpreter processes batch files internally, I won't make any guesses. It does however have a problem with :: in if statements.
I ran a test on both NT2000 and XP Profession and REM worked just fine in any combination from within the if statement.
I did run into problems when I did the following:
if 1==1 (
::Test1
::Test2
echo Test
)
This results in "The system cannot find the drive specified." on both XPPro and NT2000.
if 1==1 (
::Test1
echo Test
::Test2
)
This results in ") was unexpected at this time." on both OS's.
The following work just fine:
if 1==1 (
REM Test1
REM Test2
echo Test
)
if 1==1 (
REM Test1
echo Test
REM Test2
)
Good Luck,
Steve
As for how the command interpreter processes batch files internally, I won't make any guesses. It does however have a problem with :: in if statements.
I ran a test on both NT2000 and XP Profession and REM worked just fine in any combination from within the if statement.
I did run into problems when I did the following:
if 1==1 (
::Test1
::Test2
echo Test
)
This results in "The system cannot find the drive specified." on both XPPro and NT2000.
if 1==1 (
::Test1
echo Test
::Test2
)
This results in ") was unexpected at this time." on both OS's.
The following work just fine:
if 1==1 (
REM Test1
REM Test2
echo Test
)
if 1==1 (
REM Test1
echo Test
REM Test2
)
Good Luck,
Steve
ASKER
Yeah, I did find that REM always works.
So the rules about :: comments in multi-line blocks seem to be:
1. Don't use two :: lines in a row - "The system cannot find the drive specified."
2. Don't use a :: as the last line in a block - ") was unexpected at this time."
3. Don't use a :: followed by an empty line - "The syntax of the command is incorrect."
It does seem like we may have enough clues to figure out what is going on here.
If you are interested, here's another little puzzle:
Enter the single line batch file:
if [1]==[1] (rem test)
When you run it you'll see a blank line followed by two prompts:
c:\temp>test
c:\temp>
c:\temp>
But if you put an empty line at the start of the batch file, before the single line, you'll see:
c:\temp>test
c:\temp>c:\temp>
I'm sure this is a result of how unbalanced paretheses are handled, since the closing paren is not seen after the REM. You can prove this by putting a closing paren on the next line, and everything works as expected. However, echo is on, so you would expect to see a blank line show up BEFORE it hits the IF line, so somehow the shell is backing up a couple of times as it tries to extricate itself from the batch file.
Useless info, I'm sure.
Mark
So the rules about :: comments in multi-line blocks seem to be:
1. Don't use two :: lines in a row - "The system cannot find the drive specified."
2. Don't use a :: as the last line in a block - ") was unexpected at this time."
3. Don't use a :: followed by an empty line - "The syntax of the command is incorrect."
It does seem like we may have enough clues to figure out what is going on here.
If you are interested, here's another little puzzle:
Enter the single line batch file:
if [1]==[1] (rem test)
When you run it you'll see a blank line followed by two prompts:
c:\temp>test
c:\temp>
c:\temp>
But if you put an empty line at the start of the batch file, before the single line, you'll see:
c:\temp>test
c:\temp>c:\temp>
I'm sure this is a result of how unbalanced paretheses are handled, since the closing paren is not seen after the REM. You can prove this by putting a closing paren on the next line, and everything works as expected. However, echo is on, so you would expect to see a blank line show up BEFORE it hits the IF line, so somehow the shell is backing up a couple of times as it tries to extricate itself from the batch file.
Useless info, I'm sure.
Mark
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Those symptoms are side effects of the normal recreation of the script inside ( ) as a separate process.
First of all, starting a line with two colons is technically NOT a "comment" as a rem statement is.
The REM statement is parsed at run time like any other statement or command is.
The first colon on any line is actually telling the parser this is NOT a statement, but a label, and it is treated as any other label. The second one makes this a label with no name or a "null label", but that does not change the normal treatment of labels, that is to identify the name of the label in the first word and ignore the rest of the line. This is why some sites state that using null labels at the beginning of lines for comments is faster and more efficient than the REM statement. Certain characters can mess up the REM statement without messing up a null label line. Yes I believe them that the null label is faster since the line is not parsed, but i've never timed and calculated the difference to prove it and CERTAINLY never had enough REM statements to see performance improvements even when the REMs were completely deleted, but theory is more fun to talk about than reality.
So, now if i want a label inside a parens routine, it would have to be quoted if supported at all, and i've never bothered to try, but i suppose this might work:
:: setup flags for if
set flag1=true
set flag2=2
:: run the routine only if
if "%flag1%"=="true" (
^:^: run the thing
echo flag was true
goto inner%flag2%
^:inner1
echo this should not run when flag2 is 2
goto ^:innerend
^:inner2
echo this should run when flag2 is 2
goto ^:innerend
^:innerend
)
Again, that's just speculation and i've never found a viable purpose to give me reason to try it, i simply use real rem statements inside perens when i feel documentation is needed, and keep the null labels outside.
(\o/) Hope this helps,
2K
First of all, starting a line with two colons is technically NOT a "comment" as a rem statement is.
The REM statement is parsed at run time like any other statement or command is.
The first colon on any line is actually telling the parser this is NOT a statement, but a label, and it is treated as any other label. The second one makes this a label with no name or a "null label", but that does not change the normal treatment of labels, that is to identify the name of the label in the first word and ignore the rest of the line. This is why some sites state that using null labels at the beginning of lines for comments is faster and more efficient than the REM statement. Certain characters can mess up the REM statement without messing up a null label line. Yes I believe them that the null label is faster since the line is not parsed, but i've never timed and calculated the difference to prove it and CERTAINLY never had enough REM statements to see performance improvements even when the REMs were completely deleted, but theory is more fun to talk about than reality.
So, now if i want a label inside a parens routine, it would have to be quoted if supported at all, and i've never bothered to try, but i suppose this might work:
:: setup flags for if
set flag1=true
set flag2=2
:: run the routine only if
if "%flag1%"=="true" (
^:^: run the thing
echo flag was true
goto inner%flag2%
^:inner1
echo this should not run when flag2 is 2
goto ^:innerend
^:inner2
echo this should run when flag2 is 2
goto ^:innerend
^:innerend
)
Again, that's just speculation and i've never found a viable purpose to give me reason to try it, i simply use real rem statements inside perens when i feel documentation is needed, and keep the null labels outside.
(\o/) Hope this helps,
2K
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hello 2K,
Thanks for the input. I assume that everyone on this thread understands delayed and non-delayed expansion, since I've seen answers from most of you on the subject.
Regarding comments, it is very clear that null labels ARE supported within multi-line blocks, and they are supported like usual (no escaping necessary). If you leave echo turned on, you'll see that the :: lines don't show up at all (unlike REM lines). And, as long as you follow the three rules I stated above, everything works as expected. Commented lines are not seen, other lines are executed.
I very much agree that this is a result of how parens are processed, although I wouldn't agree with your wording that they are a separate process, as "process" has a well-defined meaning to an operating system. What I'm looking for is a description of how the paren processing interferes with the label processing, or vice versa.
Some combination of the paren processing and the label processing leads to the errors. All the errors seem to relate to the line AFTER the null label. To me, it looks like there is special code that examines the line after a label, maybe to make sure the label is a reasonable target for a goto. Or lines after a label are executed without checking that we're in a block. Somehow, this post-label-checking code runs before the code that would determine the next line is itself a label. Maybe something about how the paren processing handles the lines in the block confuses this code.
I've always thought of paren processing as moving all the lines in the block up onto a single line and placing &'s between them.
if 1==1 (
echo Test
do something
)
becomes
if 1==1 echo Test & do something
And I've thought of label processing as just ignoring everything up to the line feed. But these models don't explain the behaviour completely.
My thought is that if we can determine a more accurate model for what is going on, there might be more little caveats to worry about like the three rules above. But mostly this is just idle curiosity. We probably won't know the answer unless some MS programmer publishes a tell-all book.
Thanks for all the input, more theories are welcome,
Mark
Thanks for the input. I assume that everyone on this thread understands delayed and non-delayed expansion, since I've seen answers from most of you on the subject.
Regarding comments, it is very clear that null labels ARE supported within multi-line blocks, and they are supported like usual (no escaping necessary). If you leave echo turned on, you'll see that the :: lines don't show up at all (unlike REM lines). And, as long as you follow the three rules I stated above, everything works as expected. Commented lines are not seen, other lines are executed.
I very much agree that this is a result of how parens are processed, although I wouldn't agree with your wording that they are a separate process, as "process" has a well-defined meaning to an operating system. What I'm looking for is a description of how the paren processing interferes with the label processing, or vice versa.
Some combination of the paren processing and the label processing leads to the errors. All the errors seem to relate to the line AFTER the null label. To me, it looks like there is special code that examines the line after a label, maybe to make sure the label is a reasonable target for a goto. Or lines after a label are executed without checking that we're in a block. Somehow, this post-label-checking code runs before the code that would determine the next line is itself a label. Maybe something about how the paren processing handles the lines in the block confuses this code.
I've always thought of paren processing as moving all the lines in the block up onto a single line and placing &'s between them.
if 1==1 (
echo Test
do something
)
becomes
if 1==1 echo Test & do something
And I've thought of label processing as just ignoring everything up to the line feed. But these models don't explain the behaviour completely.
My thought is that if we can determine a more accurate model for what is going on, there might be more little caveats to worry about like the three rules above. But mostly this is just idle curiosity. We probably won't know the answer unless some MS programmer publishes a tell-all book.
Thanks for all the input, more theories are welcome,
Mark
FYI, I ran into a similar problem with multi-line comments in July 2005. I wasn't able to locate the question/answer above, so I posted a new question at
https://www.experts-exchange.com/questions/21498411/FOR-command-gives-error-but-only-when-using-colons-for-comments.html
Go there for additional discussion but the conclusion is the same, i.e. "::" is unreliable for comments and REM will work better.
I'm adding this comment so the two questions are cross-referenced for anyone with this problem in the future.
https://www.experts-exchange.com/questions/21498411/FOR-command-gives-error-but-only-when-using-colons-for-comments.html
Go there for additional discussion but the conclusion is the same, i.e. "::" is unreliable for comments and REM will work better.
I'm adding this comment so the two questions are cross-referenced for anyone with this problem in the future.