Issue with "echos"

[Gisle Vanem]

I compiled and linked a program called echos.exe from this SwsSock package:
https://www.softsystem.co.uk/products/swssock.htm

But trying to run it by echos.exe -h did not work since the internal
TCC command kicked in and wrote exe -h to the console.

Only a "echos.exe" -h worked:
Echo 2.02 (ws2_32-msvc1939-win32), edited Fri Apr 22 18:47:28 2011.
Echo client/service.

Syntax: echos [options] [host]
...
-v : Increase verbosity of output
-h : Help
-----------------

IMHO, annoying that a command with an .exe appended should be treated as an internal command.
Any way to instead need an extra space; echo .exe -h to handle it internally?
I failed to find any setdos option for it.

 

[RogerB]

You could try to disable echos with COMMANDS

Take Command / TCC Help v. 31

jpsoft.com

 

[Gisle Vanem]

You could try to disable echos with COMMANDS

No I won't. I use echos all the time on various .bat/.btm files.
But I always use it as echos foo bar. Not echos.foo bar.

 

[RogerB]

I think the problem is arising because of the support for the "echo." syntax to echo a blank line - as soon as the parser sees the dot after the "echos" it stops looking for an external programme.

I wasn't suggesting you disable the internal echos permanently, but try it and see if it works. If it does, you could create an alias, library function or batch file to wrap the disabling and enabling of the internal command around your external command.

Alternatively you could try using the full path to your external command instead, and if that works you could create an alias to simplify calling it.

 

[rconn]

As Roger said, this is a CMD compatibility issue - ECHOS duplicates the ECHO behavior with a trailing '.'.

 

[Charles Dye]

Another possibility is to quote it:

"echos" -h

This will cause TCC to look for an external.