(Windows batch) Goto within if block behaves very strangely

Question

If I take the following Windows batch code snippet and run it:

echo foo
if 1 == 1 (
    echo bar
    goto asdf
    :asdf
    echo baz
) else (
    echo quux
)

The output I would expect is:

foo
bar
baz

But instead I get:

foo
bar
baz
quux

If I comment out the goto asdf line, it gives the output I expect. The echo quux line should never be exectuted, so why is the existence of the goto causing that to happen?

UPDATE: For what it's worth, here's a workaround that correctly does what I originally intended:

goto BEGIN

:doit
    echo bar
    goto asdf
    :asdf
    echo baz
    goto :EOF

:BEGIN

echo foo
if 1 == 1 (
    call :doit
) else (
    echo quux
)

However, this doesn't answer my original question.

Answer 1

The target of a CALL or GOTO should never be inside a block statement within parentheses. It can be done, but as you see, the results are probably not going to be what you want.

The entire IF (...) ELSE (...) construct is parsed and loaded into memory before any of it is processed. In other-words, it is logically treated as one line of code. After it is parsed, CMD.EXE is expecting to resume parsing starting with the next line after the IF/ELSE construct.

After the parse phase, the complex command is executed from memory. The IF clause is processed properly and the ELSE clause is skipped properly. BUT within the IF (true) clause, you perform a GOTO :asdf, so CMD.EXE dutifly begins scanning for the label. It starts at the end of the IF/ELSE and scans to the bottom of the file, loops back to the top, and scans until it finds the label. The label happens to be within your IF clause, but the label scanner knows nothing about that detail. So when the complex command finishes executing from memory, batch processing resumes from the label instead of from the end of the complex IF/ELSE.

So at this point the batch processor sees and executes the next few lines

    echo baz
) else (
    echo quux
)

baz is echoed, and so is quux. But you might ask, "Why doesn't ) else ( and/or ) generate a syntax error since they are now unbalanced and no longer parsed as part of the larger IF statement?

That is because of how ) is handled.

If there is an open ( active when ) is encountered, then the ) is processed as you would expect.

But if the parser is expecting a command and finds a ) when there is not an active open (, then the ) is ignored and all characters on the remainder of the line are ignored! Effectively the ) is now functioning as a REM statement.

Answer 2

Anything inside a set of brackets is considdered to be a single line, processed, interpreted and executed in one hit. Your script reaches goto asdf and jumps out of that block/line. At the label :asdf, there is no bracket, so it starts reading lines one by one. It reaches else, but there's no if between :asdf and else so it ignores it.

To prevent issues like this, I always use goto or call on if and for statements, rather than blocks. This sorts out issues with further goto statements and also sorts out a lot of problems with variables too.

To use goto:

echo foo
if 1 == 1 goto bar
echo quux
goto nextbit

:bar
echo bar
goto asdf
:asdf
echo baz

:nextbit
:: more script...

Or to use call:

echo foo
if 1 == 1 (call :bar) else (call :quux)
:: more script...
exit /b

:bar
echo bar
goto asdf
:asdf
echo baz
exit /b

:quux
echo quux
exit /b

Answer 3

In this case it turns out to be related to the poor nesting and structure of a loop inside an IF statement, as clearly explained by https://stackoverflow.com/users/1012053/dbenham above.

That said, I figured out another similar consideration due to this problem... Please take a look a the following problem and subsequent solution here: ". was unexpected at this time" generated from batch script line 'if exist [file] (...

The solution was simply the treatment of '(' and ')' on ECHO lines inside an IF statement block.

The point is, do consider treatment of special characters as a possible source of a problem when troubleshooting IF (and possibly FOR) statements.

HTH