Advanced DOS batch pitfalls

The following is a collection of cases for strange behaviour when using advanced techniques in DOS batch files. You should have some basic experience in batch "programming", as I'm assuming some knowledge and not further explain the basics. For some basics I will create a tutorial to be published here very soon (reference will be posted here).

It's an Interpreter
If using complex mechanisms like subshelling (using commands enclosed in round brackets), keep in mind batch files are not really like using a programming language - batch language isn't that accurate, there are several flaws in the interpreter we have to take care of.

As   cmd.exe  being an interpreter, it reads line after line, and does some pattern replacing in advance to executing the line.
A "line" can be
* a single physical line
* several physical lines connected by a caret (^) at the end of each line
* several physical lines enclosed in round brackets

A single line is hence:
 

@echo off
                      

Select all Open in new window

if 1 == 1 (echo yes) else (echo no)
                      

Select all Open in new window

echo Writing a long ^
                      text here
                      

Select all Open in new window

if 1 == 1 (
                        echo yes
                      ) else (
                        echo no
                      )
                      

Select all Open in new window

Why should one know? As said already, it's an interpreter we use, and it's applying some string replacements.
If you are using environment variables, which is one of the things you will use every time, this gets most important.
E.g. the following code will not work as expected:
 

set example=1
                      if %example% == 1 (
                        set example=2
                        echo %example%
                      )
                      REM result:   1
                      REM expected: 2
                      

Select all Open in new window

In the first line, variable   example  is set to 1. In the next "line", containing   IF  up to the closing bracket, each occurance of   %example%  is replaced by the value set at that time, which is 1. That's why we almost always use Delayed Expansion. I will not further discuss that feature here; however, it might bring another headache in some (very advanced) cases:
 

setlocal EnableDelayedExpansion
                      set pwd=#^!pwd#
                      echo !pwd! %pwd%
                      set pwd=#^^^!pwd#
                      echo !pwd! %pwd%
                      

Select all Open in new window

Try it, and try to spot the exclamation mark ...

Escape!
That leads us to escaping. If you have to escape some control characters to override its special meaning, e.g. round brackets, pipe, percent sign, aso., you will have to escape them again for each interpreter go. Sometimes, that is. And that is the problem here, you will have to try your code ALWAYS for nested commands working as desired.
It's hard to construct examples for that, as they seem to follow no logic at all, so you will have to believe me. Working example which needs escaping is:
 

for /F "tokens=*" %%F in ('dir /a:-d . /s/b ^| find "\temp\"') do del /f %%F
                      

Select all Open in new window

The pipe character needed escaping, because it is used for piping the output of one command to the input of another. If not escaped,   cmd.exe  would try to parse it when reading the complete line, which leads to a syntax error because of incomplete   FOR.

Goto Issue
Coming back to variable expansion, oBdA ( http://www.experts-exchange.com/M_960827.html) pointed out a strange behaviour one should be aware of. See his example (extracted from http://www.experts-exchange.com/Q_24416652.html#24410829):
 

@echo off
                      set Var=Value 1
                      if 1==1 (
                        echo Var when entering the block: %Var%; setting it to "Value 2" now ...
                        set Var=Value 2
                        goto SomeLabel
                        :SomeLabel
                        echo Var is now: %Var%
                      )
                      

Select all Open in new window

This will output Var as being 2, while without   GOTO  it results in 1, the value set before the block. This is because   cmd.exe  will reinterpret the code after it executes a   GOTO. This is only a showcase, of course, noone would ever come to the conclusion having to use a goto in a block?!

The Case of the Missing Bracket
Another pitfall you might run into is accidently omitting a closing bracket. This will do NOTHING, and give you some brain work trying to debug. Example:
 

(echo Start
                       for /L %%L in (1,1,100) do echo %%L
                       echo End
                      REM --- Missing closing ")" here
                      

Select all Open in new window

Will not echo anything - because the line is never ended because of the missing ")", and the command is never executed ...

No Whitespace allowed!
Just another strange thing to note: If you try to break a line into two by using a caret, you can't use whitespace at the beginning of the line:
 

for %F in (*) do ^
                         echo %%F
                      

Select all Open in new window

will give you errors that the command " " could not be found.

Block or one-liner?
Something which might puzzle you (I am puzzled at least) is the one-liner behaviour versus using blocks:
 

if 1 == 1 echo yes & echo another yes
                      

Select all Open in new window

This line will echo both commands. I.e. the line after   IF  is handled as one command. You could expect, as   &  is the command separator, that the   IF  is evaluated up to the ampersand, and after this is starting a new command. Wrong!
 

for %F in (*) do @echo %F > output.txt
                      for %F in (*) do @echo %F >> output.txt
                      (for %F in (*) do @echo %F) > output.txt
                      

Select all Open in new window

Line 1 will write the last result into   output.txt. You could expect that the stdout redirection into a file ( > output.txt) would apply to the   FOR, but it's not, it is applied to the command ( ECHO). And that is meaning that the file is overwritten in each go of the   FOR  loop. This also means that the file is opened and closed multiple times, which is a performance issue, so even if you use the append ( >>) redirector like shown in line 2 it would be bad practice.
The third line will do what we want: collect all echo generated by the   FOR  loop, and writing it into the file all at once.

Redirecting output
Talking about redirection: Funny applications are
 

>> output.txt  echo yes
                      >> output.txt  if 1 == 1 echo This is a syntax error
                      >> output.txt (if 1 == 1 echo yes, three)
                      >> output.txt  dir c:\* | findstr MyFiles
                      >> output.txt (dir c:\* | findstr MyFiles)
                      

Select all Open in new window

The first and third line actually work, the echoed text is appended to   output.txt. After understanding the first line, the second seems to be logically correct - but instead, a syntax error is generated, stating   IF  is not expected at that position.
After adding brackets, as in third line, everything is fine.
Forth line doesn't what we want. DIR  output is stored in the file, and   FINDSTR  is acting on a empty pipe. Hence the fifth line has to be used.
As a rule of thumb, if you want to use above syntax: Complex commands, like   IF  and   FOR, which could or actually do require round brackets as part of their syntax, need to be enclosed in round brackets. Command chains ( |, &, &&, ||) have to be enclosed, too.

The following syntax is not recommended, even if working as desired - it is obscuring the meaning and hard to read:
 

dir c:\* | >> output.txt findstr MyFiles
                      

Select all Open in new window

Very handy for dynamically generated scripts, e.g. for FTP, is this syntax
 

@echo off
                      call :genscript > script.cmd
                      call script.cmd
                      exit /b
                      
                      :genscript
                      echo @echo off
                      echo dir
                      exit /b
                      

Select all Open in new window

But be aware that piping does not work. If we change above call to
 

call :genscript | findstr dir
                      

Select all Open in new window

we get the same error as if we would try to use that call on commandline. I did not find any workaround to get this running yet.


This article is subject to occasional changes. I'll post a short comment about each addition.