Using "tree" with C:\PROGRAM FILES (X86)

This topic is resolved

Share

Tagged: ,

Viewing 5 reply threads
  • Author
    Posts
    • #1535685
      PowerMe!
      Participant
      Post count: 24
      Member Points: 1,157
      Rank: Level 3

      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:

      would throw the following error.

      tree command

      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:

      tree command with folders with spaces

      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.

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

      • This topic was modified 4 months, 2 weeks ago by PowerMe!.
      0
    • #1536281
      Swapnil Kambli
      Moderator
      Post count: 49
      Member Points: 4,869
      Rank: Level 3

      Hi Ratan, By test-path I meant

      1+

      Users who have liked this topic:

      • avatar
      • #1536289
        PowerMe!
        Participant
        Post count: 24
        Member Points: 1,157
        Rank: Level 3

        Hi Swapnil,

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

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

        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.

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

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

        0
    • #1536314
      Michael Pietroforte
      Keymaster
      Post count: 1893
      Member Points: 24,844
      Author of the year 2018
      Rank: Level 4

      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:

      0
      • #1537607
        PowerMe!
        Participant
        Post count: 24
        Member Points: 1,157
        Rank: Level 3

        Hi Mike, thanks.

        Yes that works.

        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

        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

        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.

        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.

        • This reply was modified 4 months, 2 weeks ago by PowerMe!.
        0
        • #1537762
          Michael Pietroforte
          Keymaster
          Post count: 1893
          Member Points: 24,844
          Author of the year 2018
          Rank: Level 4

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

          0
        • #1537853
          PowerMe!
          Participant
          Post count: 24
          Member Points: 1,157
          Rank: Level 3

          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.
          0
    • #1537913
      PowerMe!
      Participant
      Post count: 24
      Member Points: 1,157
      Rank: Level 3

      Here you can try this.

      0
    • #1537947
      Michael Pietroforte
      Keymaster
      Post count: 1893
      Member Points: 24,844
      Author of the year 2018
      Rank: Level 4

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

      0
      • #1537976
        PowerMe!
        Participant
        Post count: 24
        Member Points: 1,157
        Rank: Level 3

        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!

        0
        • #1538045
          Michael Pietroforte
          Keymaster
          Post count: 1893
          Member Points: 24,844
          Author of the year 2018
          Rank: Level 4

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

          0
        • #1538754
          PowerMe!
          Participant
          Post count: 24
          Member Points: 1,157
          Rank: Level 3

          as I mentioned earlier

          0
        • #1539227
          Michael Pietroforte
          Keymaster
          Post count: 1893
          Member Points: 24,844
          Author of the year 2018
          Rank: Level 4

          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.

          0
        • #1541684
          PowerMe!
          Participant
          Post count: 24
          Member Points: 1,157
          Rank: Level 3

          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!

          0
        • #1542103
          Michael Pietroforte
          Keymaster
          Post count: 1893
          Member Points: 24,844
          Author of the year 2018
          Rank: Level 4

          You have to remove the last backslash. This works:

          0
    • #1543524
      PowerMe!
      Participant
      Post count: 24
      Member Points: 1,157
      Rank: Level 3

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

      1+

      Users who have liked this topic:

      • avatar
Viewing 5 reply threads
  • You must be logged in to reply to this topic.
© 4sysops 2006 - 2020

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account