%ProgramFiles(x86)% returns different values in TCC and CMD

When I type this...

echo %ProgramFiles(x86)%

...from CMD in 64-bit Windows 7 it returns the value:

C:\Program Files (x86)

When I type exactly the same ting from TakeCommand 11, in the same environment, it return this:

C:\Program Files(x86)


As far as I can tell, TakeCommand takes the parenthesis as an endpoint for the variable name and return the value of %ProgramFiles% followed by the literal text "(x86)", while CMD sees the full variable name %ProgramFiles(x86)% and returns the value for that.

This is causing me serious problems. Is this a bug? Is there a way to work around it? Escaping the parenthesis does not work. I'm not sure what else to try.

--Bob Q
 
May 20, 2008
11,391
99
Syracuse, NY, USA
echo %[ProgramFiles(x86)]

On Mon, 31 May 2010 15:12:10 -0400, bquinlan <> wrote:

|When I type this...
|
|echo %ProgramFiles(x86)%
|
|...from CMD in 64-bit Windows 7 it returns the value:
|
|C:\Program Files (x86)
|
|When I type exactly the same ting from TakeCommand 11, in the same environment, it return this:
|
|C:\Program Files(x86)
|
|
|As far as I can tell, TakeCommand takes the parenthesis as an endpoint for the variable name and return the value of %ProgramFiles% followed by the literal text "(x86)", while CMD sees the full variable name %ProgramFiles(x86)% and returns the value for that.
|
|This is causing me serious problems. Is this a bug? Is there a way to work around it? Escaping the parenthesis does not work. I'm not sure what else to try.
--
- Vince
 

dim

Dimitry Andric
May 31, 2008
205
1
Netherlands
On 2010-05-31 21:30, vefatica wrote:

> echo %[ProgramFiles(x86)]

For .bat files that need to run under CMD and TCC, I use this:

set PFDir32=%ProgramFiles(x86)%
if not "%_4VER%" == "" set PFDir32=%[ProgramFiles(x86)]%

From there on, use %PFDir32% to point to the 32-bit Program Files dir.
 

rconn

Administrator
Staff member
May 14, 2008
12,340
149
> When I type this...
>
> echo %ProgramFiles(x86)%
>
> ...from CMD in 64-bit Windows 7 it returns the value:
>
> C:\Program Files (x86)
>
> When I type exactly the same ting from TakeCommand 11, in the same
> environment, it return this:
>
> C:\Program Files(x86)
>
>
> As far as I can tell, TakeCommand takes the parenthesis as an endpoint
> for the variable name and return the value of %ProgramFiles% followed
> by the literal text "(x86)", while CMD sees the full variable name
> %ProgramFiles(x86)% and returns the value for that.
>
> This is causing me serious problems. Is this a bug? Is there a way to
> work around it? Escaping the parenthesis does not work. I'm not sure
> what else to try.

Not a bug. CMD requires both leading and trailing %'s, so it assumes that
everything within is part of the variable name. TCC allows a single leading
%, so it has to break on whitespace and what would normally be invalid
variable name characters (like the '(').

You can pass the name with dubious characters included by using the %[]
syntax; i.e.:

Echo %[ProgramFiles(x86)]

Rex Conn
JP Software
 
Similar threads
Thread starter Title Forum Replies Date
rfaquino WAD Apparently a bug when expanding environment variable %ProgramFiles(x86) Support 2
nickles WAD echo "%PROGRAMFILES(X86)%" Support 16
H variable programfiles(x86) loses space Support 1
J How to? 20beta: How to install x86 on x64 Support 2
S Tcmd 16.0.38 x86 Digital Signatures Support 0
L 15.01.54 won't install on Windows 8.1 x86 Support 2
D New 64-bit install goes to Program Files x86 Support 3
C "Program Files" .vs. "Program Files (x86)" Support 2
Frank problem with environment variable x86 vs. x64 Support 2
F %@regex["^-","-a"] returns 0, "^-" =~ "-a" is false (no match) Support 4
Peter Murschall %_BATTERY returns 0 and others Support 9
W pdir returns diff results between tcc and tcmd - one is an error msg Support 5
M Fixed PSHELL command returns error Support 2
H Fixed DIR /G returns wrong sizes Support 2
D COPY returns ERRORLEVEL 2 Support 5
Steve Pitts WAD @MD5 returns incorrect results for strings Support 2
G WAD _DOS and VER/r returns incorect value Support 2
R Function #IDOW returns only 2 characters Support 10
D @IPADDRESS[] always returns 11001 Support 8
vefatica Fixed @FILEOPEN returns 4294967295 Support 2
I Possible Bug: History /n Returns Nothing Support 3
S WAD _exit returns invalid code under some conditions Support 13
M %_ADMIN always returns 0 Support 3
B Bdebugger doesn't recognize breakpoint after batch file returns Support 2
N Delay returns immediately Support 20
J BUG: MSGBOX after DETACH returns early with 0 on Win7 Support 3

Similar threads