WAD ECHO. expansion of non-existent env-vars differs from CMD.exe

[LarryBrasfield]

There is a semi-useful variant of the ECHO command implemented by CMD.exe, and differently by TCC. This is the ECHO. variant, (although the trailing dot can be several different punctuation character.) In CMD.exe and TCC, this has the effect of suppressing the normally unwanted "ECHO is ON" (or OFF) behavior when given an empty command tail. In CMD.exe, it has the extra effect of rendering leaving %EnvVarName% constructs as entered if there is no such named environment variable, while in TCC the expansion results in an empty string. This session screen-scrape/paste demonstrates the difference (with PROMPT set to . to reduce clutter):

. cmd
Microsoft Windows [Version 10.0.17134.165]
(c) 2018 Microsoft Corporation. All rights reserved.

. echo. furd? %Furd%
 furd? %Furd%

. exit

. echo. furd? %Furd%
 furd?

.

While I do not consider the CMD.exe behavior to be a bug, TCC's "Duplicate CMD.EXE bugs" option has no effect on it.
(This is from TCC version 23.00.24.)

 

[vefatica]

In CMD, an ordinary ECHO (no dot) also leaves alone references to non-existent envvars (and doesn't add a space as ECHO. does). But then you can use ECHO. with an argument and no intervening space. Compare these.

 

[rconn]

WAD. I've been aware of this (bizarre) CMD behavior for a while (it's not limited to ECHO), and I consider TCC's behavior to be a feature. I have no intention of changing TCC's behavior, because:

1. CMD behaves differently in different versions
2. I've never been able to come up with any use case for this
3. CMD's behavior is dumb
4. CMD's behavior is undocumented
5. It would break a few zillion TCC aliases (TCC has worked this way since the 4DOS days.)
6. CMD's behavior is dumb (that gets in twice because … it's really dumb)

I might be persuaded to change the "CMD-only syntax" option in TCC to duplicate this, but never for the default TCC behavior.

 

[LarryBrasfield]

I reported this because I keep seeing intimations that TCC can be used in place of CMD to interpret batch files written for CMD. Some of those are the comments I keep seeing, here and in the TCC docs, regarding strange TCC behavior which is justified by CMD compatibility. TCC can interpret such files, in many cases, but it cannot in enough cases that I have personally abandoned my one-time quest to have TCC run .cmd files generally. CMD is difficult to program against, leading people to do the darnedest things, hardly susceptible to understanding and often relying on tricks that are not documented by Microsoft (but are published elsewhere.) Those tricks are frequently the cause of breakage, where 4NT TCC trips over something written for and undoubtedly tested against some version of CMD. (That is why only .btm files are given to TCC for interpretation on my systems.)

Yes, the CMD behavior is exceedingly dumb, mainly because it is undocumented, but also because it adds yet another quirky rule to either accommodate or trip over. (I very much appreciate the "Duplicate CMD.EXE bugs" option, unchecked!)

I found this deviation while seeking some form of echo, or a replacement for it, which acts like ECHOX but without that command's eagerness to take as input everything following it in a glommed command group.

It would be nice if SETDOS settings could be specified for specific commands or functions instead of everything at once.

 

[rconn]

I reported this because I keep seeing intimations that TCC can be used in place of CMD to interpret batch files written for CMD.

One thing I should clarify here -- CMD's behavior is different when it's at the interactive prompt, versus when it's in a batch file. When CMD is running a batch file, the non-existent variables are removed (just like in TCC). So batch file compatibility is not an issue.

 

[LarryBrasfield]

CMD's behavior is different when it's at the interactive prompt, versus when it's in a batch file.

That sort of switcheroo behavior is plain evil. Undertaking your CMD.exe compatibility quest would (further) degrade my sanity.

 

[rconn]

That sort of switcheroo behavior is plain evil.

Which is why I don't care to emulate it, and why I suspect it's a more likely a CMD bug than feature.