Skip to content

Powershell 7 Windows Explorer context menu options to open a shell at the current directory do not work properly (with fix) #14091

@rlusian1

Description

@rlusian1

Steps to reproduce

  • Install Powershell 7 and have it add the context menus to open PowerShell at the current location
  • Open Windows Explorer and go to a directory other than your Env::USERPROFILE (say c:\temp)
  • Use the PowerShell7 > Open Here or Open Here as Administrator options
  • Powershell starts up at Env:USERPROFILE

Expected behavior

  • Powershell should start up in the directory where the context menu was used (such as c:\temp)

Actual behavior

  • Powershell always starts at Env::USERPROFILE

Fix

The problem here is that the registry command sets the WorkingDirectory, but that is not the same as the directory where the shell is opened to. You also need to do a Set-Location.

This is the command as laid down by WIX in Product.wxs

C:\Program Files\PowerShell\7\pwsh.exe -NoExit -RemoveWorkingDirectoryTrailingCharacter -WorkingDirectory "%V!" -Command "$host.UI.RawUI.WindowTitle = 'PowerShell 7 (x64)'"

This is a command that actually works:

[HKEY_CLASSES_ROOT\Directory\ContextMenus\PowerShell7x64\shell\openpwsh\command]
@="C:\Program Files\PowerShell\7\pwsh.exe -NoExit -RemoveWorkingDirectoryTrailingCharacter -WorkingDirectory "%V!" -Command "$host.UI.RawUI.WindowTitle = 'PowerShell 7 (x64)'; $wdtemp=[Environment]::CurrentDirectory; Set-Location -Path $wdtemp""

As noted above, you need to do a Set-Location to get the shell to open in the desired directory. This is complicated by the issue that -RemoveWorkingDirectoryTrailingCharacter was designed to fix, but that switch does not work with Set-Location. The solution was to set the -WorkingDirectory with -RemoveWorkingDirectoryTrailingCharacter (which sets [Environment]::CurrentDirectory properly), then read that into a variable and pass that to Set-Location.

Since this is a strange sequence of commands and there might be a better way to do it, I'm leaving the final fix to the experts, but this does produce the desired behavior.

Environment data

Name                           Value
----                           -----
PSVersion                      7.1.0
PSEdition                      Core
GitCommitId                    7.1.0
OS                             Microsoft Windows 10.0.17134
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area-Maintainers-Buildspecific to affecting the buildIssue-Questionideally support can be provided via other mechanisms, but sometimes folks do open an issue to get aResolution-No ActivityIssue has had no activity for 6 months or more

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions