Yet another thread on CMD compatibility

[Patulus]

I am trying to run QT5 configure. It exits right away in TCC, but works in CMD. It doesn't matter if I set "repeat CMD bugs", the result is the same. Are there any options in TCC to make it really compatible? It comes to this line in configure.bat:

if not exist qtbase mkdir qtbase || exit /b 1

The directory qtbase exists, so CMD continues, because || refers to the mkdir result. It seems like TCC instead evaluates `if`, thinks that || is about `if`'s result and exits.

 

[Patulus]

The above incompatibility can be fixed by parenthesis, but it then continues to be incompatible in other places.

if "%SYNCQT%" == "true" (
    if not "%perl.exe%" == "" (
        echo Running syncqt ...
        "%perl.exe%" -w "%QTSRC%\bin\syncqt.pl" -minimal -version %QTVERSION% -module QtCore -outdir "%QTDIR%" %QTSRC%
        if errorlevel 1 exit /b
    ) else (
        echo Perl not found in PATH. Aborting. >&2
        exit /b 1
    )
)

TCC result:
Running syncqt ... TCC: C:\qt\qt5\qtbase\configure.bat [234] Неизвестная команда ".exe"
«Неизвестная команда» means "Unknown command".
CMD result:
Perl not found in PATH. Aborting.

 

[rconn]

This is a bug in CMD - it's not doing what you think. When an IF command fails in CMD, it discards *everything* following the IF command on the line, whether that's a conditional or compound command. So CMD isn't equating the || with the MKDIR, it's simply throwing everything away. (This AFAIK is also not documented anywhere by Microsoft.)

 

[Patulus]

Deep sigh... I read the documentation, I am aware of that bug. Read my post again. What I am concerned about is TCC is supposed to reproduce this bug, if I set the correspondent option. However this batch file doesn't work in TCC regardless of the option to reproduce the bug you mentioned.

 

[rconn]

TCC does support the CMD bug for compound commands (&) or AND's (&&), but not for OR (||) commands because of piping issues.

 

[Patulus]

Surprise. The documentation doesn't mention it. So there is no way to make TCC compatible with CMD.

 

[rps]

Surprise. The documentation doesn't mention it. So there is no way to make TCC compatible with CMD.

Can't the OR (||) case also be accomplished by testing the returned error level?
Just curious; I always use a ^ when adding a newline to a TCC If statement. Ie.

if "%SYNCQT%" == "true" ( ^
.....

Doesn't CMD use these also?

 

[rconn]

Surprise. The documentation doesn't mention it. So there is no way to make TCC compatible with CMD.

Sure there is -- you just have to use the correct syntax (i.e., with a command group), and it will work in both CMD and TCC.

This particular issue is caused by *two* problems - first, the batch file is using incorrect syntax, and second, they're relying on CMD's buggy behavior with the invalid syntax.

Since this particular syntax / bug problem has come up exactly once in the last few years, I don't think it's a critical issue.

 

[Patulus]

It's not the definition of the word “compatibility”. If I have to edit thr QT batch files for them to run in TCC, it's not compatibility.

Since this particular syntax / bug problem has come up exactly once in the last few years, I don't think it's a critical issue.

Geez..., thank you for letting me know that you don't give a damn about me. Right, $604 dollars I paid to jpsoft over the course of 12 years is not important. Wow.

 

[MaartenG]

It's not the definition of the word “compatibility”. If I have to edit thr QT batch files for them to run in TCC, it's not compatibility.

The irony of it all is that if you disable the Duplicate CMD bugs, you get the right results with your if ...|| exit command (albeit for the wrong reasons)
It also depends on what version of TCC you are: TCC's IF behaviour varies though the versions if duplicate cmd bugs was enabled. Very annoying..

The second issue (in the SYNQT script) is caused by a TCC bug: it doesn't handle the "." in a variable name right (along the longer known issues with %var% instead of %var)

[TEST]set q.r=something

[TEST]set q
q.r=something

[TEST]echo ==%q.r%==
==.r=

The workaround (not solution) for this is using %[perl.exe] (without the trailing %) instead of %pearl.exe% in TCC.


When I saw that there was a CMDDEbug released, I quickly tested it. Literally the first script I found on my machine gave an error, the second one gave a different outcome ( :-S ) and the third gave an error again. (I have to admit that many of my CMD scripts are not very straightforward).
De-installed it after 10 minutes. TCC will never have the exact same behaviour as CMD. Not possible, so not reliable.


So, *finally* my point: Why do you want to run CMD scripts in an "emulator" if the original is on every Windows machine?

 

[Patulus]

The irony of it all is that if you disable the Duplicate CMD bugs, you get the right results

No, I don't. I've mentioned in the topic post that the script doesn't work regardless of this option. It's right there, the third sentence? It reads: “It doesn't matter if I set "repeat CMD bugs", the result is the same”.

So, *finally* my point: Why do you want to run CMD scripts in an "emulator" if the original is on every Windows machine?

Yeah, the old good game that whatever is wrong is that I want something wrong. Common, I got used to Take Command over 12 years. Why not? Of course, since it doesn't work, I'll use CMD. But why I cannot ask a question how to make it work in the support forum? I paid 604 dollars for updates since 4NT version 7. What do you see wrong with that?

 

[MaartenG]

No, I don't. I've mentioned in the topic post that the script doesn't work regardless of this option. It's right there, the third sentence? It reads: “It doesn't matter if I set "repeat CMD bugs", the result is the same”.

It gives the right result on my system. Probably because of a different TCC version. But this was the irrelevant part of my message, so just ignore it.

Yeah, the old good game that whatever is wrong is that I want something wrong. Common, I got used to Take Command over 12 years. Why not? Of course, since it doesn't work, I'll use CMD. But why I cannot ask a question how to make it work in the support forum? I paid 604 dollars for updates since 4NT version 7. What do you see wrong with that?

I totally got your point (I think): TCC advertises CMD compatibility (they even have a tool to debug CMD's), you paid (very) good money for it, and now you expect results. Or at least assistance in getting results. Completely valid.

I think you missed my point: TCC will never be 100% compatible, regardless any promises/expectations . You will get disappointed and/or have a lot of debugging to do.
Just don't go that route. Leave CMD's to CMD.exe.

 

[rconn]

It's not the definition of the word “compatibility”. If I have to edit thr QT batch files for them to run in TCC, it's not compatibility.

Geez..., thank you for letting me know that you don't give a damn about me. Right, $604 dollars I paid to jpsoft over the course of 12 years is not important. Wow.

The immediate fix is to use the correct syntax for CMD and TCC (the command group) instead of relying on invalid syntax combined with an undocumented CMD bug.

The CMD IF / conditional OR bug is on my list to fix; however it's a very complex change that will take at least 2-3 more days to implement & test.

The other problem in the batch file is due to the usage of invalid variable name characters (i.e., "%perl.exe%). This is a conflict with a TCC feature - most variables only require a single leading % instead of the CMD (and COMMAND.COM) requirement for leading & trailing %. There are two possible workarounds for this in TCC:

1) Use the %[perl.exe] variable syntax to force the invalid characters into the variable name
2) Set CMDVariables=Yes in your TCMD.INI. TCC will then use the same variable name parsing scheme as CMD, requiring leading and trailing %'s for all variables. This will provide the maximum CMD compatibility, but will probably break your existing batch files & aliases.

I'd also recommend you contact the QT developers; they may not be aware they're using bad syntax.

 

[Patulus]

Just don't go that route. Leave CMD's to CMD.exe.

Any other advices what I should do in order not to get disappointed?

The CMD IF / conditional OR bug is on my list to fix; however it's a very complex change that will take at least 2-3 more days to implement & test.

It's not urgent. Thank you for the instructions how to fix the second problem!

 

[MaartenG]

Any other advices what I should do in order not to get disappointed?

Actually: I do! But that might take some time (writing in English ..).

Thank you for the instructions how to fix the second problem!

You're welcome!

 

[MaartenG]

Any other advices what I should do in order not to get disappointed?

ADVICE 1: If you are your company's admin, don't use TCC for manipulating files (like copying, moving,etc).

If I were an evil employee and I knew my admins were using TCC, I would create a file like this:

echo. > dummy%%@exec[dir%%@char[32]%%@char[47]s%%@char[32]C%%@char[58]%%@char[92]].txt

Yes, thats a valid filename ;-) Expanded, this translates to: "dummy%@exec[dir /s c:\].txt" )

Now, if you, as an admin, do a simple, innocent command like this:

for %x in (dummy*) DO set TEST="%x"

It will execute the DIR /s command on *your* computer, using *your* credentials.


Of course, now this evil employee is going to use this for much worse evil purposes: %@execstr[start /invisible zzz]
Where zzz can be a command, a BTM script, an executable, or whatever he can come up with.


If you try to prevent this from happening, you have to dismantle large parts of TCC, leaving you effectively with CMD.exe


This method works because there is no clear separation between commands (internal commands, functions, aliases, ..) and data (filenames, textstrings, filecontent, ...)



NB: If you want to try for yourself, you can create the %@char[] strings (in this case for "THIS IS A TEST") with:

for %x in (%@ascii[THIS IS A TEST]) Do echos %%@char[%x]

 

[AnrDaemon]

My only question is: WHY do you run explicitly CMD files through TCC?