For the benefit of those not familiar with safe ECHOing, here's a brief overview of ECHOs 'hidden dangers'. Take a look at the basic statement below:-
This doesn't behave as expected when VAR is set to /?, ON, OFF or when VAR is undefined. The usual workaround is to append a period immediately after the ECHO command, like this:-
However, this introduces a new problem. If VAR is undefined and the current working directory contains a file named 'echo', the following error is displayed (although the script continues to execute):-
'echo.' is not recognized as an internal or external command, operable program or batch file.
Back in May of this year in a thread titled 'ECHOing blank lines - what happened?' (See Ref#1), with the help of Simon and Frank, I concluded the safest way to echo, was to append a colon immediately after the echo command.
This is something I've been doing ever since (well... when I remember to) and in doing so, all the problems mentioned above are avoided. I've since noticed another reason to use the colon, that being to dramatically reduce the execution times of scripts containing a 'CALL ECHO' statement.
---------------------------------------------------------------------------- Minimizing the Execution Time of CALL ECHO
I've known for some time that the CALL ECHO statement observably impacts script performance, but just assumed that was due to pushing stuff onto the stack and expanding variables etc. That was until the other day.
I was writing a solution that used a CALL ECHO statement and during the testing noticed that I'd missed out 'the colon'. After adding it, the script ran as though the CALL wasn't present. Some experimentation was called for...
The first test was to compare the effect of various characters placed after ECHO without a CALL, the second with a call. Here are the two scripts:-
================ script 1 ============== @echo off for /l %%a in (1,1,500) do echoX%%a
================ script 2 ============== @echo off for /l %%a in (1,1,500) do call echoX%%a
Script 2 is obviously somewhat contrived, however it has the same effect as a script that genuinely requires a CALL ECHO statement. The scripts were edited and the X was substituted for various characters. TIMETHIS from the resource kit was used to obtain execution times. No results were recorded until the console buffer had been filled. The operating system was Windows 2000 (SP2).
As you can see the period has the worst times, it also causes problems when a file named 'echo' exists in the current directory. It seems the CALL command is iterating the PATH variable. To verify, script 2 tests were re- run, this time with the PATH variable undefined. The execution times for the colon, backslash and forward slash remained unchanged, whilst the time for the period was reduced dramatically.
It's interesting that the colon and slashes stop CMD iterating the PATH. These are all illegal filename characters so I guess CMD just doesn't bother.
So, what's the best character to use? Given that your scripts will be more reliable if using some kind of character immediately after ECHO, you may as well use one that gives the best all-round performance under all conditions and doesn't introduce new problems. That definitely rules out the period. The forward slash is clearly the best performer, hotly pursued by the colon and backslash.
I going to continue with the colon, its what I've been using for the last few months. For all the new blood out there, if you want the fastest scripts then the forward slash is the way to go.