Google Groups

Safe Echoing Revisited


Ritchie Lawrence Jul 30, 2002 2:06 PM
Posted in group: alt.msdos.batch.nt
----------------------------------------------------------------------------
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)