The following code comes from "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd", a Microsoft SDK batch file.

Code:

IF "x%TARGET_CPU%x"=="xx" (
IF /I "%PROCESSOR_ARCHITECTURE%"=="x86" SET "TARGET_CPU=x86" & SET "CURRENT_CPU=x86"
IF /I "%PROCESSOR_ARCHITEW6432%"=="x86" SET "TARGET_CPU=x86" & SET "CURRENT_CPU=x86"
IF /I "%PROCESSOR_ARCHITECTURE%"=="AMD64" SET "TARGET_CPU=x64" & SET "CURRENT_CPU=x64"
IF /I "%PROCESSOR_ARCHITEW6432%"=="AMD64" SET "TARGET_CPU=x64" & SET "CURRENT_CPU=x64"
IF /I "%PROCESSOR_ARCHITECTURE%"=="x64" SET "TARGET_CPU=x64" & SET "CURRENT_CPU=x64"
IF /I "%PROCESSOR_ARCHITECTURE%"=="IA64" SET "TARGET_CPU=IA64" & SET "CURRENT_CPU=IA64"
IF /I "%PROCESSOR_ARCHITEW6432%"=="IA64" SET "TARGET_CPU=IA64" & SET "CURRENT_CPU=IA64"
GOTO Parse_Args
)

(on my machine, it is the 3rd inner IF that triggers.)

Under CMD, this code sets TARGET_CPU and CURRENT_CPU.
Under TCC, this code sets none of the variables.

The following code (only the 3rd inner IF, not nested)

Code:

IF /I "%PROCESSOR_ARCHITECTURE%"=="AMD64" SET "TARGET_CPU=x64" & SET "CURRENT_CPU=x64"

That would be sensible - except that (1) it's undocumented, and (2) CMD also supports command groups, so if you wanted it to ignore compound commands you could just use a command group. Having it act like that only for IF makes no sense.

I haven't tried any of the above examples myself, but looking at what was posted above, it looks like TCC's behavior (with "Duplicate CMD Bugs" turned ON) is still different than CMD's behavior when it comes to *NESTED* IF statements (with the "outer" IF statement command(s) to execute being in a command group with ()'s ). Without nested IF statements and just a single IF statement with compound commands, it looks like TCC's behavior (with "Duplicate CMD Bugs" turned ON) and CMD's behavior are the same, as what I would expect with "Duplicate CMD Bugs" turned ON. It appears to be an issue with *NESTED* IF statements. Look at vefatica's first example again between TCC v21 and CMD (it's evident to me that his v21 is with "Duplicate CMD Bugs" turned ON). Again, I haven't personally tested, but am just making an observation on the output of the commands posted above.

This is an issue in TCC that is inconsistent with what the documentation states.

The documentation for the IF command states (excerpt):

When an IF test fails, the remainder of the command is discarded. Whether TCC continues with the next command on the line, or discards the rest of the line and goes to the next line is dependent upon the Duplicate CMD Bugs configuration option. CMD will discard all remaining commands on the line when an IF test fails, including those after a command separator or pipe character. If you do not want to reproduce CMD.EXE's behavior of an IF affecting all commands on a line, set DuplicateBugs to No in the .INI file. The IF behavior is different when DuplicateBugs is YES in a command group in a batch file. If there are multiple command lines in the command group, a failed IF will only ignore the remainder of the commands on that line. The commands on the subsequent lines in the command group will still be executed.

Note that it states that even with DuplicateBugs set to YES, a failed IF will only ignore the rest of the commands on that line (presumably separated with the command separator & ), and that the separate remaining lines in the command group will still be executed. TCC is clearly not doing that when "Duplicate CMD Bugs" is turned ON. All the remaining commands in the command group, even all the ones on separate lines, are discarded. Check this out:

First, what's "&|"? Guessing that it's an internal construct for implementing DuplicateBugs and delineating the actual batch file lines, the intended (?) strategy seems sound ... when the condition is false, go to the next line. But it doesn't seem to be doing that.[/QUOTE]

Administrator

This issue isn't actually about nested IF statements (which TCC handles fine), it's about what to do when a (badly-written) CMD-compatible batch file inserts additional non-IF statements inside a command group in an IF. I have made a change to 21.0.33 to match CMD's highly-erratic (and undocumented, and flat out wrong) behavior if you have the "Duplicate CMD bugs" enabled.

Thanks for the change.
I agree the syntax is awful.
I have "Duplicate CMD bugs" enabled — but I seldom bump into the category of problems this check addresses (my own scripts are obviously written in clear TCC syntax), and I didn't make the connection.