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.
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:
if 1 == 1 (echo yes) else (echo no)
echo Writing a long ^
if 1 == 1 (
) else (
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:
if %example% == 1 (
REM result: 1
REM expected: 2
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:
echo !pwd! %pwd%
echo !pwd! %pwd%
Try it, and try to spot the exclamation mark ...
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
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
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
set Var=Value 1
if 1==1 (
echo Var when entering the block: %Var%; setting it to "Value 2" now ...
set Var=Value 2
echo Var is now: %Var%
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:
for /L %%L in (1,1,100) do echo %%L
REM --- Missing closing ")" here
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 ^
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
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
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.
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)
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
, 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
Very handy for dynamically generated scripts, e.g. for FTP, is this syntax
call :genscript > script.cmd
echo @echo off
But be aware that piping does not work. If we change above call to
call :genscript | findstr dir
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.