Using SETLOCAL on the command line was mentioned in another thread. I had never used it so I played with it a bit. I don't quite understand what's happening below. In the first example, second ECHO, why is %zz still 2? In the second example why isn't the same thing echoed twice?

Using SETLOCAL on the command line was mentioned in another thread. I had never used it so I played with it a bit. I don't quite understand what's happening below. In the first example, second ECHO, why is %zz still 2? In the second example why isn't the same thing echoed twice?

I absolutely agree Vince, it shouldn’t be necessary, the parser is clearly not handling variable expansion correctly when there’s an endlocal in a situation with multiple commands on one line. I hadn’t intended my observation to be seen as a workaround, more as evidence of the problem and perhaps helping Rex identify what’s going on.

Administrator

Using SETLOCAL on the command line was mentioned in another thread. I had never used it so I played with it a bit. I don't quite understand what's happening below. In the first example, second ECHO, why is %zz still 2? In the second example why isn't the same thing echoed twice?

WAD. ENDLOCAL will expand the entire line, regardless of any command separators.

If this doesn't make any sense, it's because it's for compatibility with CMD. No, I don't know why CMD does it, and no, it isn't documented, but there are a number of batch files out there that assume this (somewhat bizarre) behavior.

Since you didn't have any apparent reason for using this syntax, I assume that this was an example and not the real purpose. Exactly what do you want to do with the ENDLOCAL?

If this doesn't make any sense, it's because it's for compatibility with CMD. No, I don't know why CMD does it, and no, it isn't documented, but there are a number of batch files out there that assume this (somewhat bizarre) behavior.

In that case I’d suggest it’s a candidate for inclusion with the other slightly warped behaviours controlled by the “Duplicate CMD.EXE bugs” directive, then it could behave sensibly for those only using TCC.

Administrator

In that case I’d suggest it’s a candidate for inclusion with the other slightly warped behaviours controlled by the “Duplicate CMD.EXE bugs” directive, then it could behave sensibly for those only using TCC.

That would be reasonable if anybody actually had an issue with the current behavior -- but it seems that the complaints / bug reports are based solely on an imaginary & non-useful syntax.

I have enough problems with the IF behavior; a lot of people turn off the "Duplicate CMD.EXE bugs" option and then file bug reports that their CMD batch files no longer work. And the IF behavior is at least comprehensible (if not sensible)!

Maybe renaming the option to something like "Emulate CMD.EXE even if strange, illogical or undocumented" would make more people who need it keep it set. Take out the word bug even though technically those things are.