Skip to main content

CMD Compatibility and CMDebug / TCC-RT, Part 1

Written by Rex Conn on . Posted in Features.

The goal of our new stand-alone batch debugger CMDebug is to run CMD.EXE batch files with as close to 100% compatibility as possible. I asked users to send me any CMD batch files they had found that didn’t work correctly in TCC.

A user sent a Microsoft batch file that failed to run in TCC (and exposed a couple of previously-unknown-to-me bugs (unfeatures?) in CMD.EXE).

The first one was in the way they called the internal SET command. For unknown reasons, the developer elected to always double quote the SET arguments, i.e.:

set "var1=insertyourvaluehere"

Now, although this was pointless, TCC (and CMDebug) didn’t have any problem parsing the command.

Are there cases where you would enclose everything in double quotes? Yes — for example:

set "var1=inserting>funny|characters&here"

If you want to use something like command separator or redirection characters, you have to quote (or escape) them to prevent the command processor from interpreting them as a special character. But in the case of this batch file, there were never any special characters in the value that required double quoting.

So, if TCC handles the double quotes, what was the problem? The developer also had some statements that looked like this:

set "var1=somevalue"andmoretexthere

TCC assumed that “andmoretexthere” should be appended to the value of var1. But what CMD.EXE actually does is ignore everything after the closing double quote, turning the line into:

var1=somevalue

This was unexpected to me (and undocumented). And f it was going to be thrown away, why did the batch file author include it? It’s not even a case of CMD looking for matching quotes – for example:

set "var1=some"value"here"and"more"here

results in:

var1=some"value"here"and"more

So CMD looks for a double quote before the variable name, and if it finds one it looks for the *last* double quote on the line and throws away everything following it. Why? Who knows? Why did the developer of this batch file add that extra text following the last quote? A typo? Excessive insider cleverness?? I have no idea.

I’ve added a kludge for this to TCC, though unless you quote the entire SET statement, you’ll never run into it.

In the next article, I’ll talk about the other issue in this batch file: a curious use of the CMD variable substitution syntax, and the CMD bug that the batch file author kludged around in a surprising (at least to TCC!) way.