Batch files: comments in multi-line blocks

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

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

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

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