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

This topic is resolved

Share

Tagged: ,

This topic contains 14 replies, has 3 voices, and was last updated by  Michael Pietroforte 2 weeks, 5 days ago.

  • Author
    Posts
  • #1535685
     PowerMe! 
    Participant
    Post count: 17
    Member Points: 837
    Rank: Level 1

    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 3 weeks, 1 day ago by  PowerMe!.
    0
  • #1536281
     Swapnil Kambli 
    Moderator
    Post count: 49
    Member Points: 4,867
    Rank: Level 1

    Hi Ratan, By test-path I meant

    1+

    Users who have liked this topic:

    • avatar
    • #1536289
       PowerMe! 
      Participant
      Post count: 17
      Member Points: 837
      Rank: Level 1

      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: 1798
    Member Points: 22,535
    Author of the year 2018
    Rank: Level 1

    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: 17
      Member Points: 837
      Rank: Level 1

      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 3 weeks ago by  PowerMe!.
      0
      • #1537762
         Michael Pietroforte 
        Keymaster
        Post count: 1798
        Member Points: 22,535
        Author of the year 2018
        Rank: Level 1

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

        0
      • #1537853
         PowerMe! 
        Participant
        Post count: 17
        Member Points: 837
        Rank: Level 1

        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: 17
    Member Points: 837
    Rank: Level 1

    Here you can try this.

    0
  • #1537947
     Michael Pietroforte 
    Keymaster
    Post count: 1798
    Member Points: 22,535
    Author of the year 2018
    Rank: Level 1

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

    0
    • #1537976
       PowerMe! 
      Participant
      Post count: 17
      Member Points: 837
      Rank: Level 1

      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: 1798
        Member Points: 22,535
        Author of the year 2018
        Rank: Level 1

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

        0
      • #1538754
         PowerMe! 
        Participant
        Post count: 17
        Member Points: 837
        Rank: Level 1

        as I mentioned earlier

        0
      • #1539227
         Michael Pietroforte 
        Keymaster
        Post count: 1798
        Member Points: 22,535
        Author of the year 2018
        Rank: Level 1

        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: 17
        Member Points: 837
        Rank: Level 1

        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: 1798
        Member Points: 22,535
        Author of the year 2018
        Rank: Level 1

        You have to remove the last backslash. This works:

        0
  • #1543524
     PowerMe! 
    Participant
    Post count: 17
    Member Points: 837
    Rank: Level 1

    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

You must be logged in to reply to this topic.

© 4sysops 2006 - 2019

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