PowerShell

[PowerMe!]

Sorry as I posted it earlier in the wrong forum! Also, my apologies to Michael Pietroforte and

Swapnil Kambli- I saw the messages late.

The problem:

$p = 'c:\Program Files (86)'
tree $p

#or

$p = "$env:ProgramFiles(x86)"
tree $p

would throw the following error.

Swapnil suggested to “have a test-path check before passing the control to tree command“. Swapnil could you explain- did you mean some thing like if(test-path $p){….}  ?

My experiment:

$p = ${env:ProgramFiles(x86)} 

tree $p

However, I have to use a variable that gets the ‘C:\PROGRAM FILES (X86)’ from a query from the registry. So I tried to simulate it as below.

$pf86 = "$env:programfiles(x86)"
$pf86 = ${$pf86}    # returns null
tree $pf86          # prints the tree for the current folder

The analogy with ${env:ProgramFiles(x86)} does not work- may be I am missing the syntax. I would love to hear.

[Swapnil Kambli]

Hi Ratan, By test-path I meant

PS C:\Users\techv> "$Env:ProgramFiles(x86)"
C:\Program Files(x86)
PS C:\Users\techv> Test-path "$Env:ProgramFiles(x86)"
False
PS C:\Users\techv>

[PowerMe!]

Hi Swapnil,

got it. You are right. If you notice the error on the tree, it somehow misses “c:\”

 C:\Users\Ratan\desktop> $p = "$env:programfiles(x86)"; tree $p
Folder PATH listing for volume Windows
Volume serial number is 2E3F-D6FD
C:\PROGRAM FILES(X86)
Invalid path - \PROGRAM FILES(X86)      #<<<<<<<<<<<<<<<<
No subfolders exist

when one uses $v = “$Env:ProgramFiles(x86)”, it will parse it as:

C:\Users\Ratan\desktop> $v = "$Env:ProgramFiles(x86)"; $v
C:\Program Files(x86)

where as the actual folder is ‘C:\Program Files (x86)’, that is the reason Test-Path is failing. If I try the string literal using ‘..’ it does return true.

C:\Users\Ratan\desktop> $v = 'C:\Program Files (x86)' ; Test-Path $v
True

Something is wrong with the parsing. Setting it to a variable using

${env:ProgramFiles(x86)}

as I did earlier works. But I am not sure how use the same for a variable.

[Michael Pietroforte]

If you post in the wrong forum, just let me know. I can move the topic.

I am unsure what you are trying to accomplish, but did you try this:

$p=$env:ProgramFiles
tree $p

[PowerMe!]

Hi Mike, thanks.

Yes that works.

$p=$env:ProgramFiles ; tree $p

But things fail when you go for $env:ProgramFiles(x86) or you store ‘C:\Program Files (x86)‘ to a variable, as in the screenshots above.

I figured out the trick would be to create a variable like below

$d= ${env:ProgramFiles(x86)}
tree $d

But the problem is I have the folder address stored in a different variable (e.g., $x) and I don’t know how create a ${$x}. There is Microsoft Doc and I read your article on 4SysOps too.

4sysops

Microsoft doc

A little background of my project:

I have an unresponsive security software that cannot be uninstalled from the control panel or the usual methods. One has to delete stuff manually- registry keys, folders and driver files. My approach to the problem was the following.

1. Get the installLocation or uninstall key from registry

$appString6432 = 'badSoftware'
$reg6432 = 'HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
$app6432 = Get-ItemProperty $reg6432 | Where-Object {$_.DisplayName -like $appString6432}
$Path_app = $app6432.InstallLocation

2. D0 a “tree” on $Path_app to find out the directory structure for that app. There is a nice way to achieve this on Mac.

sudo pkgutil --only-dirs --files com.vendor.pkg.security-agent | more

3. Proceed on manually removing them after the necessary NTFS permission tweaks

It affected a large number of users. Therefore I was trying to do a script – dealing registry keys especially while remoting to users computers was a mess. So was going to individual folders and files.

[Michael Pietroforte]

Did you check if C:\Program Files(x86) actually exist on the machine? If it does, this works:

$p = "$env:ProgramFiles(x86)"
tree $p

[PowerMe!]

Yes I tried that. Here is the problem.

1. When you put, $env:ProgramFiles(x86) inside “”, it removes the space between Programfiles and (x86). Therefore it will fail.
2. The Windows folder is “C:\Program Files (x86)” – there are 2 spaces in the string along with the parentheses.
3. They deal with it in the environmental parameter by taking away the spaces. Also if you try on ISE $v = $env:ProgramFiles(x86), it will add {} to set a variable.

[PowerMe!]

Here you can try this.

$appString6432 = '*acro*'     # assume you have adobe acrobat on the computer or replace it with any other app
$reg6432 = 'HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
$app6432 = Get-ItemProperty $reg6432 | Where-Object {$_.DisplayName -like $appString6432}

$InstallLocation= $app6432.InstallLocation

tree $InstallLocation

[Michael Pietroforte]

Yeah strange. Seems to be a bug. Why don’t use $p =${env:ProgramFiles(x86)} ?

[PowerMe!]

As you see in the original script I am using to get the address from the registry, I have to use the variable returned from $InstallLocation.

I guess I could set a check if it is “C:\Program Files (x86)” $p =${env:ProgramFiles(x86)}. But honestly, why would they stick that kind of folder naming while everyone knows its not code-friendly!

[Michael Pietroforte]

I am sorry, I can’t follow. Which code does not work?

[PowerMe!]

as I mentioned earlier

$appString6432 = '*acro*'     # assume you have adobe acrobat on the computer or replace it with any other app
$reg6432 = 'HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
$app6432 = Get-ItemProperty $reg6432 | Where-Object {$_.DisplayName -like $appString6432}
 
$InstallLocation= $app6432.InstallLocation
 
tree $InstallLocation

[Michael Pietroforte]

Yeah I saw that. But where are you using the environment variable for the programs folder? Can you describe what exactly your problem is? You can’t assume that everyone knows how Adobe stores its data in the Registry.

[PowerMe!]

Sorry about the confusion.

Registry does not give you an environmental variable but a complete path as I have shown below. I was using that environmental variable as as an example. Let me explain my code and logic.

1. Registry is one of the options to explore applications in a code. There are 2 locations:

• 64bit: HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\
• 32 bit: HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\

2. Below is an example of Adobe Acrobat that uses 32 bit.

(Sorry Wordfence won’t let me share the script in the script mode.)

$appString6432 = ‘*acro*’ # assume you have adobe acrobat on the computer or replace it with any other app
$reg6432 = ‘HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*’
$app6432 = Get-ItemProperty $reg6432 | Where-Object {$_.DisplayName -like $appString6432}

$InstallLocation = $app6432.InstallLocation

Running on the PS terminal:

C:\Users\Ratan> $InstallLocation
C:\Program Files (x86)\Adobe\Acrobat Reader DC\ C:\Users\Ratan> tree $InstallLocation
Folder PATH listing for volume Windows
Volume serial number is 2E3F-D6FD
C:\PROGRAM FILES (X86)\ADOBE\ACROBAT READER DC\
Invalid path – \PROGRAM FILES (X86)\ADOBE\ACROBAT READER DC\
No subfolders exist

So, the code gives you a variable $InstallLocation with a value of C:\PROGRAM FILES (X86)\ADOBE\ACROBAT READER DC\ . When you process that variable you get an error. Something is missing in my understanding of PS variables!

[Michael Pietroforte]

You have to remove the last backslash. This works:

$p = "C:\PROGRAM FILES (X86)\ADOBE\ACROBAT READER DC"
tree $p

[PowerMe!]

You are right! Thanks that works. Let me trim the ‘\’ at the end of the string in the script.

[Author]

Posts