Why the PowerShell Working Directory and the PowerShell Location Aren't One in the Same

Every process on a Windows system has a working directory associated with it when the process starts. Simply put, when an application has to work with pathnames, it assumes that any bare filenames or partial paths are relative to the working directory.

The reasons for this setup are pretty easy to demonstrate. Suppose you're in the Cmd.exe console shell and you're navigating through your home directory structure looking at files and folders. To get a listing of the files in that folder beginning with the letter a, you type

dir a*

at the command prompt. Because Cmd.exe always starts out in the home directory, it sees this as a partial name and assumes you want to see names starting with the letter a in the working directory. This assumption saves a lot of repetitive typing. It also makes it much easier to write scripts or use applications that deal with special subsets of files in particular locations.

You can change your working directory in Cmd.exe by using the CD command. Relative paths will then be resolved based on that new working directory.

What's important to understand about PowerShell is that although PowerShell's location is analogous to the working directory, the location is not the same thing as the working directory. In fact, PowerShell doesn't touch the working directory.

Here's what happens. When PowerShell starts up, it has a working directory just like any other application. This is typically the user's home directory. Internally, PowerShell exposes a location as a convenience for PowerShell-native tools; initially, that location is the user's home directory.

You can change your location by using the Set-Location cmdlet or its aliases sl and cd. The location can be anywhere accessible to PowerShell providers, including disk directories, registry paths, and data stores that are structured like disks. Through it all, PowerShell cmdlets and scripts can refer to items in their current location with relative names.

However, it gets confusing if you use an external application or API that works with files. Let's say you're JaneUser on a Vista system, and your home directory is C:\Users\JaneUser. You start up PowerShell and change your location to C:\tmp with the command

Set-Location C:\tmp

Inside PowerShell, your location is C:\tmp. However, your working directory is still going to be C:\Users\JaneUser. You can verify this through the CurrentDirectory property exposed by the Microsoft .NET Framework's System.Environment class by running the command

\[Environment\]::CurrentDirectory

Why is this important? Well, any external application or API that expands filenames by default is going use the working directory of its parent process; for PowerShell, this is still going to be C:\Users\JaneUser. So .NET methods such as the WebClient's DownloadFile need extra help if you want them to resolve bare filenames relative to the PowerShell location.

PowerShell was designed this way because the working directory concept was inadequate—PowerShell needed to expose data stores such as the registry as working locations. It would have been possible to change the working directory to any valid file-system location, but this has some significant security issues. Changing the working directory to a directory of interest makes an application vulnerable to content in that directory. This wouldn't affect PowerShell or PowerShell-native tools, but Windows-native applications would be exposed to spoof attempts.

The upshot of it all is that when you're running Windows-native applications or calling Windows APIs from PowerShell that directly use named files, the working directory is never going to follow your file-system location.