WAD echo "%PROGRAMFILES(X86)%"

[nickles]

echo "%PROGRAMFILES(X86)%"

under TCC returns "C:\Program Files(x86)" - note the missing blank between "s(" - where CMD correctly returns "C:\Program Files (x86)".

When fixing this, could you give my long-standing request to NOT require CTRL-X to make TAB complete paths starting with a variable (e.g. "%SYSTEMROOT%\s[TAB]") a reconsideration?

 

[Steve Fabian]

See my new suggestion in FEEDBACK re last paragraph.

 

[Charles Dye]

echo "%PROGRAMFILES(X86)%"

under TCC returns "C:\Program Files(x86)" - note the missing blank between "s(" - where CMD correctly returns "C:\Program Files (x86)".

I think that should be:

echo "%[programfiles(x86)]"

Without the square brackets, the variable name ends at the open parenthesis.

 

[nickles]

@Charles: Thanks for the workaround.

However, I think TCC should be compatible with CMD here. There's no reason (except for the usual "CMD is buggy", or "the parser interprets this so and so" comments) why TCMD's behavior should be different here. I mean, this is very basic stuff, a Windows system variable!

Maybe I'm a little bit over-sensitive here, but I think that over the last n releases stuff has been added to TCMD (like external file viewers, unpackers, et al.) that I really don't need, and other - from my point of view - more important things (e.g. the one from my post above) have been left out... Of course, my point is very subjective; others may be quite happy with the changes. I'm not.

 

[Charles Dye]

However, I think TCC should be compatible with CMD here. There's no reason (except for the usual "CMD is buggy", or "the parser interprets this so and so" comments) why TCMD's behavior should be different here. I mean, this is very basic stuff, a Windows system variable!

While I can't speak for Rex, I think I understand the reasoning here. JP's shells have worked this way since 4DOS days; changing the behavior to match CMD.EXE is likely to break thousands of existing batch files.

 

[rconn]

echo "%PROGRAMFILES(X86)%"

under TCC returns "C:\Program Files(x86)" - note the missing blank between "s(" - where CMD correctly returns "C:\Program Files (x86)".

When fixing this, could you give my long-standing request to NOT require CTRL-X to make TAB complete paths starting with a variable (e.g. "%SYSTEMROOT%\s[TAB]") a reconsideration?

WAD (since 4DOS 2.0 in 1989), and it will never be "fixed", as it would render almost all TCC batch files and aliases inoperable.

CMD requires leading and trailing %'s to delineate a variable (unless it only wants a leading %, as in FOR, or two leading %'s, as in FOR in a batch file). TCC only requires a single leading % in all cases, but that assumes that you're not going to try to embed invalid characters in your variable name.

There are two solutions:

1) Use the TCC %[xx] syntax
2) Set CMDVariables=YES in your TCMD.INI, which tells TCC to always require leading & trailing %'s for non-FOR variables. If you have existing batch files or aliases using the TCC single % syntax, you'll have to rewrite all of them, but TCC will now behave *exactly* the same as CMD (for good or bad).

 

[nickles]

While I can't speak for Rex, I think I understand the reasoning here. JP's shells have worked this way since 4DOS days; changing the behavior to match CMD.EXE is likely to break thousands of existing batch files.

It would break on a "(" in variables? Consulting the help files, the parentheses are merely used in command grouping, in FOR loops, with EXCEPT, and SELECT (maybe I missed something), but in nothing related to variables...

Anyway, I don't see a "reasoning" here, merely a glitch; the "fault" of not foreseeing that Microsoft would ever use a "(" in a system variable (what a stupid idea, Microsoft!) can hardly be put on Rex, but not "fixing" this would be another sad development.

 

[nickles]

@Rex: You noticed that I used two "%"s in my sample?

A cite from the docs (CMDVariables): "TCC allows you to specify variables with only a single leading %; CMD requires both a leading and a trailing %. Normally TCC is able to detect this, but if you have variable names with embedded whitespace (a bad idea!) TCC will not expand the variable." Now, PROGRAMFILES(X86) does not contain a single white space. Also, I don't see why accepting a "(" in a variable name - which, as I said is a stupid "invention" by the responsible MS guys - would break "almost all TCC batch files"...

 

[Charles Dye]

It would break on a "(" in variables? Consulting the help files, the parentheses are merely used in command grouping, in FOR loops, with EXCEPT, and SELECT (maybe I missed something), but in nothing related to variables...

See HELP ENVIRONMENT for the list of valid environment variable-name characters in TCC (alphanumerics, underscore, dollar sign) and the use of square brackets.

As for the characters allowed in CMD.EXE.... I've never seen them documented anywhere! Does anyone know of such a list?

 

[Steve Fabian]

..which, as I said is a stupid "invention" by the responsible MS guys

Didn't you mean irresponsible?

 

[rconn]

Also, I don't see why accepting a "(" in a variable name - which, as I said is a stupid "invention" by the responsible MS guys - would break "almost all TCC batch files"...

The '(' by itself isn't the issue -- changing TCC to accept that as a valid variable name character would probably only break a few tens of thousands of TCC batch files & aliases. (Still enough to generate a firestorm of complaints.)

The real issue is that recent versions of CMD assume that *anything* that is enclosed in %'s is a variable name. Way back when, it was decided (by near-unanimous user request) not to duplicate that behavior in 4DOS / 4NT / TCC, but to instead offer a simpler single leading % to delineate a variable name. This has been extensively documented for many years in the help file, and there is zero chance this is going to change -- it is a extension / feature of TCC, not a bug.

If you want CMD's behavior, just use the CMDVariables directive in TCMD.INI. You can't have CMD's behavior and TCC's behavior simultaneously; you'll have to choose one or the other.

 

[Steve Fabian]

If you want CMD's behavior, just use the CMDVariables directive in TCMD.INI.

Can the OPTION command be used to change the behavior dynamically, or is this a directive evaluated only during TCC start-up? If the former, it is easy to write a .BTM wrapper around and .CMD file requiring it:

xxx.btm
option //cmdvariables=yes
call xxx.cmd
option //cmdvariables=no

 

[Charles Dye]

How about an .INI option to control whether or not parentheses are legal in variable names? Default it to NO, and the firestorm would be reduced to those who choose to change it.

 

[Frank]

... and tomorrow another irresponsible MS guy introduces a new weird character used in a variable ...

I stumbled about that problem, too. But I like and can live with the %[xx] syntax.

 

[rconn]

Can the OPTION command be used to change the behavior dynamically, or is this a directive evaluated only during TCC start-up?

It can be changed dynamically.

 

[drwtsn32]

Another TCC-only solution is to use %@shfolder[42]

 

[nickles]

As "%[xx]" is a supported syntax, please make variable expansion work on e.g. "dir %[PROGR[tab]". Now - using "dir %PROG[tab]" - I end up with the expansion "dir %PROGRAMFILES(X86)", but in order to use it, I will have to add the brackets "manually" to make it "dir %[PROGRAMFILES(X86)]".