26

Simple question:

If I use the ${env:ProgramFiles(x86)} variable in a PowerShell script on a 32-bit system does it return "C:\Program Files" or is it undefined?

On a x64 system it will be mapped to "C:\Program Files (x86)" when running in both x64 and x86 mode. I don't have a 32bit system to test on, but I hope that it will be mapped to the "C:\Program Files" folder so I can use it to refer to x86 programs on any system.

Greg Bray
  • 14,929
  • 12
  • 80
  • 104
  • If you're developing for both architectures you should really test on both. – Ash Burlaczenko Sep 25 '13 at 21:21
  • I have a request in for an x86 environment but figured this would be documented somewhere. Couldn't find it online anywhere :-( – Greg Bray Sep 25 '13 at 21:24
  • 1
    possible duplicate of [What is the best way to program against powershell's x64 vs. x86 variability](http://stackoverflow.com/questions/602060/what-is-the-best-way-to-program-against-powershells-x64-vs-x86-variability) – Anthony Neace Sep 25 '13 at 21:30

1 Answers1

37

${env:ProgramFiles(x86)} is not defined on a 32-bit machine. You can test against $null to verify that.

Keith Hill
  • 194,368
  • 42
  • 353
  • 369
  • 6
    Thanks! I ended up using the -ne operator "Null coalescing" from http://stackoverflow.com/a/17647824/17373 to do this: `$dir = (${env:ProgramFiles(x86)}, ${env:ProgramFiles} -ne $null)[0]`. Not pretty but it works. – Greg Bray Sep 25 '13 at 22:48
  • 1
    Just to be precise, on a 32bit system, the environment variable is not defined, so for example if you do `dir env:` it won't be present. However, PowerShell returns $null if you try to access a variable that doesn't exist. – StephenD Sep 27 '13 at 08:35
  • @StephenD Yeah, that's more accurate. I've updated the answer. – Keith Hill Sep 27 '13 at 15:38