Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Fixed Set "VAR=VAL" format causes problems

M

Mel Davis

Apr
42
0
I've attached a batch file that is causing problems under TCMD. The file does not set variable VAR as expected; the output is:
****
**
***

If I do nothing more than uncomment the 'echo HERE' line at line 11, the output changes to
HERE
****
** aaa
***

I suspect the problem lies in the format to the SET VAR command at line 10.
This SET "VAR=VAL" command, with the enclosing quotes, is a common construct is Microsoft's batch files. (My test file is based on the structure of the :print_vscmd_header in the VsDevCmd.bat file in Visual Studio 17.) This same construct is used in several places in MSVS's batch files.

It is also used in several places in Anaconda's python virtual environment scripts.

If I'm correct in that the problem is caused by the placement of the quotes in the SET command, could you add support for it? In earlier versions of MSVS, I think I needed to change just one place in MS's batch files to get it to work under TCMD. But with the latest release of MSVS, it is much more of a problem.

NOTE: I categorized this as a bug, because even if you did not intend to support the SET "VAR=VAL" construct; simply adding an echo should not change the variable's value.
 

Attachments

Having written and viewed batch files (and now .btm files) since the early days, I don't recall ever having seen a "set" command taking that form — with the quotation-marks.

For about 15 years I worked at the Evil Empire itself. There were lots of .bat files to be seen there (for some reason C++ developers are enamored of them). In fact one department had an entire build process composed entirely of interlocking .bat files. I had occasion to look at them a number of times and years later still haven't recovered from the experience. Many "set" statements to be seen in all of those .bat files — none containing the quote-marks.

What is the purpose or advantage to the quotation-marks? Would TCC users benefit from being able to use them? Or to look at it another way: what loss might there be in not using them?
 
I vaguely recall an earlier discussion around this. I would be very surprised if support for it was not already in the product. Do you have "Duplicate CMD.EXE Bugs" enabled in TCC?
 
mikea said:
(for some reason C++ developers are enamored of them).
Click to expand...
To clarify: I used to show them .btm files and how much more they offered. Typical developer response: "Nah, I can do that with a batch file [meaning .bat or .cmd]" even though the 4NT and later TCC script commands shown would never be easily do-able with a simple cmd.exe .bat or .cmd file. Like the man said: Oh, well.
 
I don't think it's the SET command. SET does support that syntax. It has something to do with IF and the parentheses. These work:

Code: 
if "%VAR_ALT%"=="" set "VAR=aaa"

if "%VAR_ALT%"=="" (set "VAR=aaa" & rem)

And this doesn't work:
Code: 
if "%VAR_ALT%"=="" (set "VAR=aaa")
 
@vefatica
But, in the script I uploaded, if I change only line 10 to: set VAR=aaa (without the quotes) and the ECHO at line 11 is still commented out, it works. I still think it is a problem with the quotes in the SET command.
 
Mel Davis said:
@vefatica
But, in the script I uploaded, if I change only line 10 to: set VAR=aaa (without the quotes) and the ECHO at line 11 is still commented out, it works. I still think it is a problem with the quotes in the SET command.
Click to expand...
Yes, I knew that. It's certainly not SET alone, but some odd interaction of SET with IF and parentheses.
 
@vefatica
Yes, you are right. It does seem to be some combination of SET and IF. I had not really considered the IF portion of it. So, it does seem to be a bug, then.
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate