effect of CMDVariables on parameters

[Rich Skorski]

I think I found a bug in the way the CMDVariables option effects parameters, be it in TCC/LE or my understanding of how parameters are specified. It's not a big deal for me, but I wanted to share to see if it is a bug or if somebody here can help me understand what's going on.

To see the problem, take this batch script:

echo off
echo The param is %1
echo The param is %1%

And run it with CMDVariables on and off. I get this output:

CMDVariables=yes
    D:\>test.bat ohai
    echo off
    The param is %1
    The param is ohai%

CMDVariables=no, or when ran in CMD
    D:\>test.bat ohai
    echo off
    The param is ohai
    The param is ohai

I came across this problem with a batch file I was running using TCC/LE ver 13.06.77, and reading these forums I learned about the CMDVariables option. The problem boiled down to use of the %programfiles(x86)% environment variable, so turning CMDVariables on let TCC/LE handle the parens in the variable name.

With the option on, some other batch file started to break. These are all batch files that were written for Windows' cmd. One in particular is the vcvars32.bat some of you may know from Visual Studio.

 

[rconn]

Your syntax isn't valid -- "%1%" is meaningless in TCC (and CMD). Batch variables always only have a leading %, and you can't use environment variables with numerals only, as they will always be interpreted as a batch variable.

What's happening is that both TCC and CMD are discarding the trailing % because it doesn't have a variable name following it. When you set CMDVariables, TCC is looking for a trailing % following the trailing %, can't find one, and decides you must have meant to enter a literal %.

 

[Rich Skorski]

The trailing % is there just to show that I can trick TCC into recognizing the batch variable, hopefully pointing out the cause of the bug. I should have mentioned that. Notice that the second line of the script uses the correct syntax, but it has the incorrect output when CMDVariables is on.

 

[rconn]

Fixed in 16.01.45.