Create a PowerShell script for Windows PATH variable cleanup

Transcript - Create a PowerShell script for Windows PATH variable cleanup

Editor's note: The following transcript has been lightly edited for length and clarity.

Brien Posey: Hello, greetings and welcome. I'm Brien Posey. Today, I want to show you some problems that can occur because of how PATH is configured. I also want to show you how to use PowerShell to detect and help resolve some of those problems.

As you can see, I have the Windows System Properties sheet open on screen right now. I'm going to click Environment Variables. Then, I will select PATH in the System variables section and click Edit.

This is my PATH. What you see right here is a standard PATH. We have a few entries that Windows created, such as %SystemRoot%\system32 and %SystemRoot%. We also have a PATH created by a third-party application: C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR.

Problem 1: PATH size limitations

This machine doesn't have a lot installed on it, but if a machine is application-heavy, this PATH can become quite long. This brings up the first problem that can occur: a PATH that's too long.

Your total PATH size -- and when I say, "total PATH size," I mean everything on the screen combined -- can't exceed 2,048 characters. If you have many third-party applications that add to the PATH, the PATH can quickly grow and, in extreme cases, exceed the maximum PATH size that Windows sets. That's one problem you could run into.

Problem 2: Nonexistent PATH entries

Another problem that you could end up running into is that you may have a PATH that points to folders that no longer exist.

Let me show you what I mean. I'm going to go ahead and click New, and I'm going to enter C:\Temp1. Temp1 is now part of the PATH. If I go to File Explorer, you can see that I have a Temp1 folder. If I were to erase that, Temp1 would be gone, but the PATH would still exist. I could click OK to close that out and click Edit again, and you can see that we still have a reference to Temp1 even though the folder no longer exists.

If you end up with an excessively long PATH, one way to pare it down is to look for references to no longer existing folders.

I will add Temp1 back in because we will use it a bit later in this video.

Problem 3: Duplicate PATH entries

That brings me to another potential problem you could encounter: duplicate PATH entries.

For example, if I click New and type C:\Temp1, nothing stops me from adding another instance of Temp1 even though it's already in the PATH. We now have two duplicate entries. That, in and of itself, isn't necessarily a problem, but it does mean you're taking up unnecessary space within the system PATH.

To show you another problem that can exist, I need to add one more location to the PATH. I'm going to click New, and I'm going to add C:\Temp2. I'll click OK, and our PATH now includes a couple of references to Temp1 and then to Temp2.

Let me go ahead and close this out. I want to show you why what I just did matters.

Problem 4: Command conflicts

I will show one of the more serious and common problems with the system PATH. If you look at the screen, you can see that I've got File Explorer open and I'm looking in the Temp folder. I've copied a couple of Windows utilities to this folder. The first one is calc.exe. If I double-click on calc.exe, it opens the Windows Calculator. The other one is write.exe, which is a leftover from long ago, but it's a lightweight word processor that's a part of Windows.

We have two executables that function as standalone programs, and I've just copied them from the C:\Windows\System32 folder to my Temp folder. I want to copy one of these to my Temp1 folder and the other to my Temp2 folder. As you'll recall, both of those are in the PATH. Then, once I've copied these, I'm going to rename them, and I'm going to give them identical names.

I'll start with write.exe. I'll right-click on that and then choose Copy. I'll go to C: and Temp1. I'll right-click and select Paste. Then, I'll right-click again and choose Rename, and then I'm just going to call this MyProgram.exe. Next, I'll go back to the root folder and then go into Temp, and I'll do the same thing with calc.exe. I'm going to right-click on calc.exe and choose Copy, and I'll go to C:, and this time, I'll go to Temp2. I'll click Paste, then right-click and Rename. I'll also call this MyProgram.exe.

The problem is that we have two locations in the PATH that contain identical executables, but the executables do two different things. Which one is going to execute? Well, let's find out.

I'll go to the terminal and open a Command Prompt window. I'll go to my root directory and type myprogram. I'll press Enter. It looks like write.exe executes.

Why does write.exe execute as opposed to the calculator? Well, let's take a look. In the System Properties sheet, I'll click on Environment Variables. I'll select my PATH and click Edit. You can see that Temp1 appears before Temp2 on the list. If I open File Explorer, go to Temp1, and double-click on MyProgram.exe, that opens Write.exe. Because the PATH found Temp1 before it found Temp2, it ran the copy of the program in Temp1. If we wanted to run the program in Temp2, we would have had to go directly to it. For example, I could type:

cd temp2 myprogram

This time, the calculator opens.

How do you fix a problem like that? Modifying the PATH is the only way, but I've created a PowerShell script that can help.

Overview of the PowerShell script

This script is designed to check for various common problems related to the system PATH.

Scrolling down to the script's bottom, we have the Demo Flow.

• The first thing the script tests is the PATH Structure. The only thing this does is list the various elements that are a part of the system PATH.
• From there, the script looks for duplicates. As you'll recall, we've got two instances of Temp1 in the system PATH. That's a duplicate, and the script should be able to find it.
• Next, we have Command Resolution. In other words, we're looking for one specific command. Because a command called MyProgram.exe is stored in two different places, this script should be able to help us find it.
• Finally, the last thing I'm doing is backing up the system PATH. If we find problems, we'll need to make changes to the PATH, so it would be a good idea to have a backup copy just in case anything goes wrong.

Let me run the script, and once you see how it works, I'll walk you through the code.

However, before I run the script, I must point out that when you open PowerShell, it reads the environment variables once. If you look at the environment variables in PowerShell and you get something unexpected, you can fix it by closing out and reopening PowerShell. Everything should be fixed. If you're unsure whether PowerShell will show the correct environment variables, then you must type $env:path and press Enter, and you can see the system PATH. Here you can see C:\Temp1, C:\Temp1 -- the duplicate Temp1 entries I created -- and C:\Temp2.

One crucial thing I want to point out, and we'll come back to this later, is that a semicolon separates each PATH element. This will be important when we start looking at our code.

With that said, let me go ahead and clear the screen. Let's run the script.

The first thing the script does is look at the PATH Structure. We're listing all the individual elements within our PATH. Here, we have C:\Windows\system32, C:\Windows, C:\Windows\system32\Wbem, and so on. We have C: Temp1 and its duplicate when we go further down the list. We then have C: Temp2 and the User PATH.

We come to the section meant to look for duplicates. We have duplicate entries being detected. The duplicate entry is C:\Temp1, and the script tells us Count: 2. In other words, two occurrences of C:\Temp1 are listed within our PATH. Right away, we know there is a problem. Temp1 is in our PATH statement twice. The information up here verifies this as well. Here, we have two occurrences of Temp1. That's certainly something that we would want to fix.

Let's go ahead and fix it. I'll select one occurrence of C:\Temp1 and click Delete and OK. I'll click OK again. We must close and reopen PowerShell; otherwise, the changes won't be recognized. I will pause the video for one second while I do that.

I've closed and reopened PowerShell. Let me go to my Scripts folder and run the script.

This time, when we look at the PATH Structure, we see only one instance of C:\Temp1. If we look at the Duplicate Detection section, we see: 'No Duplicate Entries Found In Path.' We fixed the problem right away.

In the next section, we see Command Resolution. We're searching for MyProgram. As you'll recall, I had two separate executables that are referred to as MyProgram. What we're doing here is exploring all the different locations specified within the PATH to see if MyProgram exists. We can see that MyProgram was found in C:\Temp1 and again in C:\Temp2. It's called MyProgram.exe in both cases, which means we have a conflict. That's a problem we want to resolve.

The very last thing I'm doing is backing up the PATH. The backup section says, 'PATH Variable Backed Up To: C:\Users\Brien\AppData\Local\Temp\PATHBackup.txt.' Let's look at what that looks like.

In File Explorer, I'll go to C: and then Users, Brien, AppData, Local and Temp to locate and open my PATHBackup file. I'll go ahead and open that. It shows the backup of the system PATH.

Let me go ahead and close this out. Let's look at the script.

Breaking down PowerShell code

We have our script, and I'm not going to step through every single line of code because this script is a little bit long. But let's look at how this works.

I'll scroll down to the bottom because this is where the demo process begins. The very first thing we do is check the PATH Structure. We have a Write-Host command, which displays the words "PATH Structure" in yellow. Then, we call the function Show-PathVisualization.

If I scroll up, here's the Show-PathVisualization function:

Function Show-PathVisualization {

      $PathDirs = $Env:Path -Split ';'

      Write-Host "`nCurrent PATH Structure: `n"

      ForEach ($Index In 0..($PathDirs.Count - 1)) {

           Write-Host ($PathDirs[$Index])

      }

}

We're creating a PATH variable called $PathDirs and setting it equal to $Env:Path. You'll recall I showed you a command you could use to display the PATH in PowerShell earlier. This was the command right here. But I'm appending -Split and then ';'.

I mentioned that a semicolon separated every element within the PATH. In this script, we split the line every time a semicolon is encountered, so each element within the PATH is stored in a separate location.

I've got a Write-Host statement that displays nCurrent PATH Structure: `n on the screen. In case you were curious, this backward apostrophe n (`n) you see indicates that we want to move to a new line.

We have a ForEach loop, which loops through all the elements we've extracted from the PATH.

Then, we're using a Write-Host statement to display each one of those individual elements.

Then, if we go down here, the next thing we're doing is looking for duplicates. We display the words "Duplicate Detection," then call a Get-DuplicatePathEntries function. Here's the Get-DuplicatePathEntries function:

Function Get-DuplicatePathEntries

{$PathDirs = $Env: Path -Split ';' | Where-Object { $_ -And ($_ -Ne '') }

$Grouped = $PathDirs | Group-Object

$Duplicates = $Grouped | Where-Object { $_.Count -Gt 1 }

 

If ($Duplicates) {

      Write-Host "`nDuplicate Entries Detected:`n"

      ForEach ($Group in $Duplicates) {

           Write-Host ("- {0} (Count: {1}) -F $Group.Name, $Group.Count)

      }

} Else {

      Write-Host "No Duplicate Entries Found In Path."

}

}

We're first creating a variable called $PathDirs, setting that to our PATH, and splitting that at the semicolon. Then, we've got a Where-Object, and we're checking to ensure we don't have any blank spaces.

Next, we create a variable called $Grouped. We're looking at the PATH directories and grouping objects. In other words, we're taking duplicates that might exist and grouping those duplicates. Then, I'm creating a variable called $Duplicates, and I'm setting that equal to $Grouped where the object count is greater than 1. In other words, we're adding that anywhere a duplicate exists to $Duplicates.

We have If ($Duplicates) -- so, in other words, if duplicates exist -- then Write-Host 'Duplicate Entries Detected.' Then, for each $Group in our $Duplicates, we're using Write-Host to display the duplicate count on the screen, and we're also displaying the $Group.Name and the $Group.Count. In other words, we're looking at how many duplicates exist for each duplicate entry that's found. If no duplicates exist, we use this Write-Host statement right here to say, 'No Duplicate Entries Found In Path.'

The next thing that we're doing is Command Resolution:

Get-ExecutableResolution -CommandName "MyProgram"

I'm calling a function called Get-ExecutableResolution, and I'm passing a -CommandName as a parameter, and the -CommandName that I'm passing is MyProgram. As you'll recall, I renamed two standard Windows programs to MyProgram. That's why this says MyProgram; I'm looking for that. You would replace this with the name of any program you're particularly interested in finding. If I scroll up, we get to the Get-ExecutableResolution function:

Function Get-ExecutableResolution {

      Param (

           [Parameter(Mandatory = $True)]

           [String]$CommandName

      )

 

      Write-Host "Searching For: $CommandName`n"

 

      $PathDirs = $Env.Path -Split ';'

      ForEach ($Dir In $PathDirs) {

           If ([String]::IsNullOrWhiteSpace($Dir)) { Continue }

          

           $Candidate = Join-Path -Path $Dir -ChildPath $CommandName

           $CandidateExe = "$Candidate.exe"

 

           If (Test-Path -LiteralPath $Candidate) {

                 Write-Host "$CommandName Found: $Candidate" -ForegroundColor Cyan

           } ElseIf (Test-Path -LiteralPath $CandidateExe) {

                 Write-Host "$CommandName Found: $CandidateExe" -ForegroundColor Cyan

We have a parameter section where we're passing the command name we're searching for. Then, we're using Write-Host to display that we're searching for that command name. Once again, we're creating a variable called $PathDirs and setting it to equal all the entries within our list. Then, there's also a check in here for safety. We're looking for white space or null values. The next thing I'm doing is creating a variable called $Candidate. For that, I'm using Join-Path. I'm specifying the directory as the main PATH to join the PATH, and then the -ChildPath will be the $CommandName. Then, I've got $CandidateExe, and what I'm doing is I'm taking $Candidate, which is the PATH in the $CommandName, and then I'm appending .exe. We end up with the full PATH and file name.

We've got a few If and Else statements that we're using to check to see if our file exists in the various locations within the PATH. Write-Host controls all these lines of output, saying that either the $CommandName was not found in a particular location or it was found.

The last thing we're doing is creating a backup. To do that, I'm calling a function called Backup-PathVariable. Here is that function:

Function Backup-PathVariable {

      Param (

           [String]$BackupFile = "$Env:TEMP\PathBackup.txt"

      )

      $Env:Path | Out-File -FilePath $BackupFile -Encoding UTF8

      Write-Host "Path Variable Backed Up To: $BackupFile"

}

As you can see, I have a parameter defined, a string called $BackupFile. I'm setting that equal to "$Env:TEMP\PathBackup.txt." It essentially provides me with the PATH where this backup file is stored. You could substitute a literal PATH if you wanted to. Next, I take $Env:Path and pipe that to Out-File. That writes the contents of our system PATH out to a file. Then, we have -FilePath, and we're using $BackupFile. We're encoding this as UTF8. Finally, we're displaying a message when all that is done, saying, "Path Variable Backed Up To: $BackupFile."

That's how that script works.

I'll go ahead and run this one more time for you. You can see the different sections. First, we look at the PATH Structure, check for duplicates, and then perform the Command Resolution to determine if our target command exists in multiple locations within the PATH. Finally, we perform a backup.

That's just a quick way to use PowerShell to search for common problems with the system PATH.