"echo," instead of "echo." or "echo\"

[jeb]

Hi,

the problem:
If you want to echo a variable that could be empty you can not use

Code: Select all

echo %var%

because the output is not empty, instead you got "echo is enabled (on)" or something similar.

So most people use the echo. trick

Code: Select all

echo.%var%

This works, but fails if you have anywhere in your path a file named "echo".
Then you got an error (echo. could not be found ...)

As I wrote in the topic http://www.dostips.com/forum/viewtopic.php?f=3&t=1226
you can use instead

Code: Select all

echo\%var%

This works in the most situations.

But as I learned from aGerman's code, not in all situations.
Because if var begins with . you got the same error(echo. could not be found ...)
or with var=..\myCommand.bat it will start myCommand

So I try some other possibilities and found the (currently) best way.

Code: Select all

echo,%var%
or
echo;%var%

This seems to be bullet proof, and it is faster than the others, because the path will not be scanned for files.
On my system it is 15% faster than the echo. variant

[aGerman]

Thanks, jeb. I will do some experiments. The semicolon sounds interresting, because I know it as EOL sign.

Regards
aGerman

[ByteAnalyser]

Thank you very much jeb, I was looking interested at this post some time ago: viewtopic.php?p=2537 for doing things the right way. And with your precisation of this post I think I will always use

Code: Select all

echo;

in future

Thanks and Regards

[jeb]

Now one year later ...

I would recommend only ECHO(, as it seems to be the only bullet proof way to echo any content.

See the explanations here ECHO. FAILS to give text or blank line - Instead use ECHO/

jeb

[dbenham]

What about Aacini's suggestion of ECHO= viewtopic.php?f=3&t=2617

I can't find anything wrong with that, and it is less confusing to look at.


Dave Benham

[alan_b]

I started the witch hunt against ECHO.
and have since used without problems the final solution of ECHO(
I was however uneasy because ECHO) was NOT a valid solution even though ')' it seemed to comply with the same naming rules as '('.

I very recently had problem totally unrelated to ECHO :-
SET "COMMAND=('findstr /n "^" %2')"
is not suitable for use with
for /f %%i in %COMMAND% do ( .... )

I was correctly advised to remove the () brackets from the definition of COMMAND and to wrap in use as i.e. (%COMMAND%)
This increases my fears of strange side effects pertaining to how CMD.EXE processes '('

I am definitely marching with my feet and switching to the use of ECHO=

Thank you very much

Alan

[dbenham]

Hi alan

The parser obviously does not treat ( and ) symmetrically.

( is only a special character when the parser is expecting a command or a FOR IN() clause.

) is only a special character when there is an active ( preceding it

Code: Select all

c:\>(echo (hello world)
(hello world

c:\>echo (hello world)
(hello world)

C:\>(if a==a echo match)
match

C:\>(if not a==a) echo no match
) was unexpected at this time.

C:\>if (a==(a echo match))
match))

C:\>if not (a==a) echo no match
no match

I suppose the situation is a bit more complex since ) can act like a remark if the parser is expecting a command and there is no active (

Code: Select all

C:\>) this text is ignored
C:\>
C:\>echo ok & ) this text is ignored
ok

C:\>

Dave Benham

[aGerman]

I still prefer echo( since echo= displays the help with

Code: Select all

echo=/?

That's the same effect jeb showed with

Code: Select all

echo/?
echo,/?
echo;/?

Regards
aGerman

[dbenham]

Thanks aGerman. You convinced me to stay with echo( as well.

Dave Benham

[Judago]

I compiled all of the issues I could find with echo delimiters into a single list with explanations. I know they can all be found on this site(and even this thread), just thought it would be useful to bring them all together.


Using a dot will fail if a file named "echo"(no extension) exists in the current directory when passed a blank line or a line that starts with a delimiter:

Code: Select all

echo.

The colon and backslash can execute scripts in the current directory using a special relative path. The below would both execute "script.bat" in the current directory:

Code: Select all

echo:\..\script.bat
echo\\..\script.bat

The comma, equals sign, semicolon and forward slash can execute the echo help text:

Code: Select all

echo=/?
echo,/?
echo;/?
echo/?

The plus sign, opening and closing bracket can execute scripts named "echo?.bat"(where "?" is the delimiter used), these scripts can be in either the current or a path directory. To fail the rest of the line must either be blank or the first character must be a delimiter. In addition it only seems to fail if executed within a script independent of other structures such as for loops and parenthesis marked code blocks.

Code: Select all

echo+
echo[
echo]

Edited per jeb's findings.

[jeb]

A simple test, if an ECHO<someChar> works could be to test against these lines

on
off
?
/?
Next line is empty
""
\..\fail.bat
.\..\fail.bat
Carets^^^^ ^^^^!

Code: Select all

@echo off
cls
setlocal EnableDelayedExpansion
echo ERROR: External file started %%~f0 > fail.bat
set "char=+"
call :echoTest
del fail.bat > nul 2>nul
exit /b

:echoTest
echo ##### Test with "echo!char!" #####
echo echo ERROR: External file started %%~f0 > echo%char%
echo echo ERROR: External file started %%~f0 > echo%char%.bat
setlocal DisableDelayedExpansion
for /F "delims=" %%T in (echoTest.txt) do (
   set "line=%%~T"
   echo%char%%%~T
)
endlocal
del echo%char% > nul 2>nul
del echo%char%.bat > nul 2>nul
echo(

exit /b

But then you got the result that echo(, echo+, echo[ and echo] all work with all lines
I was confused, as I self wrote that +[] didn't work, as they fail if a file "echo+.bat" would exist.
Even on the cmd-line they work perfectly!

But then I discovered the problem (and that new to me, unknown batch behaviour)

On a single line, outside of any parenthesis this fails, if echo+.bat exists
echo+
But these ones work

Code: Select all

echo+!emptyVar!
(echo+)
(
echo+
)

The first one can be explained, it's caused by the parser phases, so the line isn't empty in the "important" phase.

But I never saw that command behaviour depends, if it is inside or outside of parenthesis

Currently, I haven't any clue what the underlying cause can be
But it's good to find sometimes new behaviour

jeb

[Judago]

That is really odd behaviour, I though that not working from the command line was strange enough.

I found another one, and it surprises me that it doesn't seem to look for the file.

Code: Select all

cmd /c echo+

I'm not sure what is causing but it does seem like different parsers treating the delimiters differently.

[dbenham]

Given that ECHO+ works from the command line, I think the CMD /C ECHO+ behavior is to be expected since it is running within a command line context, even if launched from within a batch file.

Dave Benham