Powershell: Can't find "powershell" in context menu when I am in windows libraries

[chucklu]

1. I want to open powershell by right click in windows libraries
   You can check this issue https://github.com/git-for-windows/git/issues/1229

2. I hope you can just provide an menu as “open powershell here” instead of powershell then two submenus.
   I already set the powershell open as Administrator by default.

[mklement0]

@chucklu:

• PowerShell _Core_ currently doesn't come with _any_ shell integration on installation, as far as I can tell, so I can encourage you to open a new issue to ask for that.

• Recent editions of _Windows 10_ have switched from offering Open command window here (cmd.exe) to Open PowerShell window here (powershell.exe) _when you hold down Shift before right-clicking_.

  • This works even inside libraries when you click on a _specific folder_.
  • By contrast, it doesn't - and conceptually _cannot_ work - if you right-click an _abstract library category_ such as Document or the _window background_ while in the libraries view, given that a library location by definition is not a _single_ location, but a _collection_ of locations.

The latter shell integration seems to come with the _OS_ (and, as an aside, is currently broken if the target folder path contains ') and only targets _Windows PowerShell_, not PowerShell Core (which is what this repo is about).

instead of powershell then two submenus

Can you be more specific? Where do you see that?

[chucklu]

The two submenus come with 6.1.0 , just right click on desktop, it will show these two submenus.
It's boring for me to choose open here and open as Administrator.
I already set it open as Administrator by default.

I have checked what you said. The powershell here only worked when I right click on one folder of library.

What I want is when I right click in folder(just the blank space in folder), then I can see the powershell here.
When I want to use powershell, I will first open the target folder, then right click in it , then open the command.
Most time ,I already in target folder, it's not convenient for me back to the top folder.

[mklement0]

@chucklu:

Ah, I see - I hadn't noticed the File Explorer integration, because I've been installing via Chocolately: I now see that there's an opt-in File Explorer context-menu integration in the installer (wizard) GUI.

The issue you describe affects Windows 7 (not sure about 8.1), not Windows 10.

To summarize the linked issue, in order to get the context-menu commands when right-clicking in the background (empty space) of a folder navigated to via the _Libraries_ view, you need a separate registry entry at:

[HKEY_CLASSES_ROOT\LibraryFolder\background]

This probably needs to be added here.

As for not wanting the context-menu command to be _nested_: please open a new issue.

[chucklu]

The issue you describe affects Windows 7 (not sure about 8.1), not Windows 10.
I am using win10, the version is

PS C:\Users\clu\Desktop> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.1.0-preview.1
PSEdition                      Core
GitCommitId                    v6.1.0-preview.1
OS                             Microsoft Windows 10.0.16299
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[mklement0]

@chucklu:

Thanks - you're right, it affects Windows 10 too (not sure what I tried earlier to wrongly convince me otherwise).

However, the problem is somewhat mitigated by the fact that the Libraries view is no longer offered _by default_ on Windows 10.

Either way, we know what the fix is.

[chucklu]

@mklement0 I have submit a new issue https://github.com/PowerShell/PowerShell/issues/6599 for the second problem.
Thanks a lot!

[iSazonov]

Upcoming Windows 10 versions will offer "Sets" - it is new desktop conception. In addition, the lifetime of Windows 7 ends.
So I guess there's no point adding integration with libraries for one-two release.

[mklement0]

@iSazonov:

Upcoming Windows 10 versions will offer "Sets"

Yes, but that doesn't seem to be related to how File Explorer's context menus are defined.

Given that the Libraries view is still a part of Windows 10, despite being hidden by default, my vote is for making this fix, which sounds simple enough.

[iSazonov]

I have no categorical objections.

[bergmeister]

@mklement0 I would be happy to add this to the existing list of registry entries (there are already 4 sets to support context menu on folder, background, Desktop and Drive, therefore this would just be another in the same style). Thanks for the pointers already. I will do this soon (in 1-2 weeks), therefore expect it to be present in preview3.
The more important question is why the chocolatey package has not got an option for this feature since the MSI has properties to allow for that via quiet (=non-UI) install as well. The properties are documented in this issue at the moment: https://github.com/PowerShell/PowerShell-Docs/issues/2007
Cc @DarwinJS @SteveL-MSFT @sdwheeler

[DarwinJS]

@mklement0 - chocolately packages don't typically try to expose every configuration option of an underlying installer.

However, Chocolatey natively supports passing arguments to the installer the package calls.

I just tested this an it works without any changes to the package:

choco install -pre -confirm powershell-core --install-arguments='"ADD_EXPLORER_CONTEXT_MENU_OPENPOWERSHELL=1"'

I will add the above to the description of the package since it is challenging to know this exists if you haven't really dug into chocolatey.

[mklement0]

That's great to know, @DarwinJS, and thanks for adding it to the package description.

[DarwinJS]

It would be nice if this context menu also added the same two run options to .ps1 files.

[mklement0]

@DarwinJS: Good idea, but I suggest you create a new issue for that.

[DarwinJS]

Why isn't the MSI cleaning up old paths?

[iSazonov]

Please open new Issue if the package has a bug.

[DarwinJS]

I have opened a couple issues - also one with the name for the REGISTER_MANIFEST property.

Wanted to mention here that in order to use these arguments you should use the powershell-core chocolatey package directly, not the pwsh package.

Once the arguments the MSI can receive seems more stable, I will add official chocolatey package parameters that will be better behaved for passing through from virtual packages like "pwsh"