On Tuesday, July 30, 2002 3:06:51 PM UTC-6, Ritchie Lawrence wrote:
> ----------------------------------------------------------------------------
> Background
>
> 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:-
>
> ECHO %VAR%
>
> 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:-
>
> ECHO.%VAR%
>
> 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...
>
> ----------------------------------------------------------------------------
> Method
>
> 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).
>
> ----------------------------------------------------------------------------
> Results
>
> Script 1
> +--------------------------------+---------+
> | Characters Tested |Time (ms)|
> +--------------------------------+---------+
> | <space> + [ ] / ; | 380 |
> +--------------------------------+---------+
> | . : \ | 450 |
> +--------------------------------+---------+
>
> Script 2
> +--------------------------------+---------+-------------------------------+
> | Characters Tested |Time (ms)| Time (ms) with PATH undefined |
> +--------------------------------+---------+-------------------------------+
> | / | 600 | 600 |
> +--------------------------------+---------+-------------------------------+
> | : \ | 630 | 630 |
> +--------------------------------+---------+-------------------------------+
> | <space> ; | 991 | 891 |
> +--------------------------------+---------+-------------------------------+
> | + [ ] | 4636 | 771 |
> +--------------------------------+---------+-------------------------------+
> | . | 7330 | 921 |
> +--------------------------------+---------+-------------------------------+
>
> 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.
>
> ----------------------------------------------------------------------------
> Conclusion
>
> 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.
>
> --
> Ritchie
> set mail=%mail:do=%
>
> ----------------------------------------------------------------------------
> References
>
> #1 'ECHOing blank lines - what happened?'
>
>
http://groups.google.co.uk/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&th=ea31bcfac07e02af&seekm=3d05d7c3_2%40mk-nntp-1.news.uk.worldonline.c
> om&frame=off
>
> If link is broken, search Google groups for "ECHOing blank lines - what
> happened?" (include the quotes)
Could you condense your conclusions a bit ?
Thanks.