GOTO this thread FOR surprising thing to see.

[npocmaka_]

user3577444 asked these two questions on stackoverflow 1 ;2

and found some interesting GOTO behavior:

Code: Select all

goto :no_such_label >nul 2>&1 || echo this is printed 
echo this not

.Here's jeb's answer:

This is a really strange and interessting bug!

The cause will be obvious when I used CALL instead of GOTO.

Code: Select all

goto :notExist || call :someLabel

You get an error message like

Code: Select all

Illegal to call a label outside of a batch file.

Obviously the parser switches to a cmd-line context here!

This is done when the first goto fails to find the label.
When you use first a call all works fine.

Code: Select all

call :noLabel 2>nul || goto :thisWorks

This seems to be a general side effect of a failing goto.
When a goto fails, it normally stops immediatly the batch file.

But with the || operator the next command will be forced to execute.

But it seems that it works more like an exit /b, so you can use this effect to leave a function.

Code: Select all

@echo off
setlocal DisableDelayedExpansion
set var=111
call :myFunc
set var
exit /b

:myFunc
setlocal EnableDelayedExpansion
set var=222
goto :noLabel 2>nul || set var=333!var!
echo This will be never reached
exit /b

The interessting output

Code: Select all

var=333!var!

So the goto :noLabel acts like an exit /b and it also done the implicit ENDLOCAL before the part || set var=333!var! is executed.

The same issue (but without the || operator) was discussed at Dostips: Rules for label names vs GOTO and CALL

But I accidentally found that in this case GOTO does not break the brackets context:

Code: Select all

   @(
     goto goto :no_label_ >nul 2>&1 ||  break just fills the line
     echo what a surprise 
   )
   echo never printed

And the next step was to check if it breaks the FOR context:

Code: Select all

 

   @echo off
   setlocal enableDelayedExpansion
   
   for /f "tokens=1,2,3" %%a in ("1 2 3 ") do (
      set /a n=1+1
      goto :no_label_ >nul 2>&1 ||  break just fills the end of line
      echo brkackets context is not broken
      echo(
      echo and so variables cannot be accessed
      set "n2=something else"
      echo -%n%- and -%n2%-
      echo but more delayed expansioon does not work --^> !n!  :-(
      echo(
      echo and for context is not broken!!!!
      echo %%a--%%b--%%c
      echo pass a command line parameter to check the output of this:
      echo ~"%~1"~
   
   )
    echo never printed

In fact I cant see much usage of this but its interesting.

[jeb]

Hi npocmaka,

In fact I cant see much usage of this but its interesting.

But it can be useful for testing the cmd line parser from a script.
That's much better than typing all the tests on the command line manually.