This behavior, if intentional, is crazy. When you execute other programs, or (as in my case) use COM objects, they won't think the current directory is the directory that the user thinks is the current directory.
What's the deal? Does it behave this way because PS has the concept of locations that don't actually exist (such as when you cd into the registry hive)? If so, then shouldn't there be (an obvious) way to get/set the actual working directory, or better yet,
if the "location" is an actual directory, shouldn't the current working directory be set as well?
Thanks, I couldn't have figured out for myself that GetCurrentDirectory() would have the sister SetCurrentDirectory() *rolls eyes*. I know how to work around the problem, the question is why it exists? And if there's some reason it must exist (yeah,
right) then why isn't it thoroughly documented?
I'm liking Powershell so far. Like everything else, there's warts, but all in all it's fairly well thought out and very powerful. But this particular behavior really baffles me.
I can see why you would think that cd would change the application's working directory. But I can also see why the location within powershell would be different from the powershell application's working location. To me it is more of an issue of scope
than a bug. GetCurrentDirectory is the current working folder of the PowerShell application and cd changes the working location IN the PowerShell app.
If your scenario is a bug, the running:
would have to be a equivalent of running:
cd "c:\program files"
and you would expect the prompt to change as well, but it doesn't.
I would be curious to see the response from someone on the powershell team. I would guess they made a conscience decision to leave System.IO disconnected from Mocrosoft.PowerShell.Core\Filesystem.. and I would bet that it does have something to do with the
Set-Location command using providers that can be extended. Kind of difficult to link System.IO to Microsoft.PowerShell.Core\Filesystem if the underlying provider can be changed.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.