Tech Off Thread

4 posts

PowerShell and the current directory

Back to Forum: Tech Off
  • wkempf

    Not sure how to contact anyone on the PowerShell team, so I'm posting here.  I've found what I must call a bug in PowerShell.  Here's how to reproduce it.

    Start PowerShell, which will put you in $home (for me, this is H:\).

    PS H:\> cd 'C:\Program Files'
    PS C:\Program Files> get-location

    Path
    ----
    C:\Program Files


    PS C:\Program Files> [System.IO.Directory]::GetCurrentDirectory()
    H:\
    PS C:\Program Files>

    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?

  • JChung2006

    [System.IO.Directory]::SetCurrentDirectory("C:\Program Files")

  • wkempf

    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.

  • bbrian

    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:
    [System.IO.Directory]::SetCurrentDirectory("C:\Program Files")
    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 closed

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.