A collection of incompatibilities with CMD.EXE

[Raistlin]

Here is a couple of TCC's incompatibilities with CMD.EXE I've discovered. To check any of them, create file Test.cmd, paste an example there, save Test.cmd and run it first under TCC.EXE then under CMD.EXE and compare outputs.

1. set aaa=c:\windows\
for %%a in (%aaa%nul) do echo %%~dpa

2. setlocal enabledelayedexpansion
set Prm1=Test
for /l %%a in (1,1,1) do (
echo !Prm%%a!
)

3. [supposing there is an empty folder "C:\Empty\1 1" with short name C:\EMPTY\110994~1]
if exist 110994~1\nul echo

4. setlocal enabledelayedexpansion
call :a c:\windows\
call :a c:\windows
exit /b
:a
set DirName=!%1!
echo %DirName:~-1%

5. verify other 2>nul
call :a && echo b
exit
:a

6. verify other 2>nul && (
echo 1
echo 2
)

7. [run Test.cmd with parameter ""]
set testString_=%1
echo %testString_%

8. setlocal enabledelayedexpansion
set s=123
for /L %%c in (0,1,255) do (
set si=!s:~%%c,1!
if defined si set charCount=%%c
)
echo %charCount%

9. set aaa="bbb"
if [^%aaa:~,1%] == [^"] echo ###

10. setlocal disableextensions
set a

 

[Raistlin]

Can I please hope that these incompatibilities will be gone with next releases?

 

[rconn]

Raistlin wrote:

> Here is a couple of TCC's incompatibilities with CMD.EXE I've discovered. To check any of them, create file Test.cmd, paste an example there, save Test.cmd and run it first under TCC.EXE then under CMD.EXE and compare outputs.

You didn't say which version of TCC you're using, or which version of
CMD (they vary slightly in different Windows versions).

> 1. set aaa=c:\windows\
> for %%a in (%aaa%nul) do echo %%~dpa

This appears to be at best an undocumented and useless CMD peculiarity,
though it's more likely just a bug. (CMD is turning "c:\windows\nul"
into "\\.".)

> 2. setlocal enabledelayedexpansion
> set Prm1=Test
> for /l %%a in (1,1,1) do (
> echo !Prm%%a!
> )

TCC doesn't supported embedded variables in delayed expansion variables,
as this would require crippling the parser to not allow dynamic variable
expansion (thus duplicating the CMD behavior). This would also break
most existing batch files, so I doubt it would be too popular with the
rest of the users.

> 3. [supposing there is an empty folder "C:\Empty\1 1" with short name C:\EMPTY\110994~1]
> if exist 110994~1\nul echo

CMD and TCC behave identically, provided you turn on SFN file searching
(OPTION/Startup) in TCC. But I wouldn't recommend it, as it can result
in some very unpleasant results with commands like DEL.

> 4. setlocal enabledelayedexpansion
> call :a c:\windows\
> call :a c:\windows
> exit /b
> :a
> set DirName=!%1!
> echo %DirName:~-1%

Duplicate of #2.

> 5. verify other 2>nul
> call :a && echo b
> exit
> :a

CMD undocumented behavior/bug - it's interpreting the conditional
command "&&" as a batch argument.

> 6. verify other 2>nul && (
> echo 1
> echo 2
> )

The TCC parser is stricter than CMD, and only allows command groups for
internal commands where it makes sense to have a command group, like
FOR, IF, IFF, etc. There's no reason to use one in VERIFY (which is a
no-op command anyway in CMD).

> 7. [run Test.cmd with parameter ""]
> set testString_=%1
> echo %testString_%

CMD and TCC behave identically here.

> 8. setlocal enabledelayedexpansion
> set s=123
> for /L %%c in (0,1,255) do (
> set si=!s:~%%c,1!
> if defined si set charCount=%%c
> )
> echo %charCount%

Another duplicate of #2.

> 9. set aaa="bbb"
> if [^%aaa:~,1%] == [^"] echo ###

CMD bug - it's ignoring the escape char in the first argument.

> 10. setlocal disableextensions
> set a

WAD - see the docs for SET. SET behaved this way before this was added
to CMD, so it didn't make sense to remove a feature in order to match an
"occasional" feature in CMD.

Rex Conn
JP Software

 

[Raistlin]

Another incompatibility. Executing following batch file

@echo off
call :aaa || echo Error
exit /b

:aaa
exit /b 1

will give different results under TCC and CMD (see in my signature for their versions).

 

[rconn]

> Another incompatibility. Executing following batch file
> Code:
> ---------
> @echo off
> call :aaa || echo Error
> exit /b
>
> :aaa
> exit /b 1
> ---------
> will give different results under TCC and CMD (see in my signature for
> their versions).

CMD's behavior is undocumented and (apparently) useless -- why do you need
it?

Rex Conn
JP Software

 

[Raistlin]

Why useless? It's a comfortable way to check if a subroutine returned an error, instead of additional "if errorlevel 1..."

Take Command Console (TCC) - A command processor compatible with CMD.EXE

It is not, actually. I agree that a lot of incompatibilities I've described above is a result of CMD.EXE creators' mistakes, but they are really used as features, because CMD.EXE is poor of "real" features. So TCC IMHO should be able to emulate these bugs if it is called "compatible with CMD.EXE". Maybe via "CmdBugs = On" (while default is Off) in INI file, doesn't matter. Now I just need to add at the beginning of my scripts:

for %%A in ("%ComSpec%") do if not %%~nxA == cmd.exe (
  cmd.exe /c %0 %*
  exit /b %errorlevel%
)

Why can't I just use TCC directives instead of CMD.EXE's ones? Because these scripts are also used in admin tasks. They should work on any computer.
I believe I'm not alone in that.

 

[rconn]

> ---Quote---
> *Take Command **Console* (*TCC*) - A command processor compatible with
> CMD.EXE
> ---End Quote---
> It is not, actually. I agree that a lot of incompatibilities I've
> described above is a result of CMD.EXE creators' mistakes, but they are
> really used as features, because CMD.EXE is poor of "real" features. So
> TCC IMHO should be able to emulate these bugs if it is called
> "compatible with CMD.EXE". Maybe via "CmdBugs = On" (while default is
> Off) in INI file, doesn't matter

It is impossible to be 100% compatible with CMD, because:

1) CMD isn't compatible with CMD (different versions behave differently)

2) In many cases (as in your latest example) CMD has belatedly added a
feature that 4DOS / 4NT / TCC has had for years. That means I either have
to break everybody's existing aliases & batch files, or accept that the CMD
behavior is going to be different.

3) And the only way to be 100% compatible is to eliminate all the extra TCC
features, which would result in a product that not many people would care to
use ...

Rex Conn
JP Software