Using "tree" with C:\PROGRAM FILES (X86)
Tagged: powershell, tree
- This topic has 14 replies, 3 voices, and was last updated 2 years, 9 months ago by
PowerMe!.
- AuthorPosts
- Wed, Nov 13 2019 at 7:44 am #1535685
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.
- Wed, Nov 13 2019 at 11:20 am #1536281
- Wed, Nov 13 2019 at 12:54 pm #1536289
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.
- Wed, Nov 13 2019 at 7:15 pm #1536314
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
- Thu, Nov 14 2019 at 5:12 am #1537607
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.
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.
- 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.
- Thu, Nov 14 2019 at 5:40 am #1537762
Did you check if C:\Program Files(x86) actually exist on the machine? If it does, this works:
$p = "$env:ProgramFiles(x86)" tree $p
- Thu, Nov 14 2019 at 5:58 am #1537853
Yes I tried that. Here is the problem.
- When you put, $env:ProgramFiles(x86) inside “”, it removes the space between Programfiles and (x86). Therefore it will fail.
- The Windows folder is “C:\Program Files (x86)” – there are 2 spaces in the string along with the parentheses.
- 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.
- Thu, Nov 14 2019 at 6:10 am #1537913
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
- Thu, Nov 14 2019 at 6:19 am #1537947
Yeah strange. Seems to be a bug. Why don’t use $p =${env:ProgramFiles(x86)} ?
- Thu, Nov 14 2019 at 6:25 am #1537976
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!
- Thu, Nov 14 2019 at 6:41 am #1538045
I am sorry, I can’t follow. Which code does not work?
- Thu, Nov 14 2019 at 9:04 am #1538754
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
- Thu, Nov 14 2019 at 6:32 pm #1539227
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.
- Fri, Nov 15 2019 at 9:57 am #1541684
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 existSo, 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!
- Fri, Nov 15 2019 at 7:06 pm #1542103
You have to remove the last backslash. This works:
$p = "C:\PROGRAM FILES (X86)\ADOBE\ACROBAT READER DC" tree $p
- Mon, Nov 18 2019 at 7:18 am #1543524
- AuthorPosts
- You must be logged in to reply to this topic.