New
#60
Update:
eleposh2.zip
They let you add/remove the Shift+Right-click context menu option to Open PowerShell here / Open PowerShell here as administrator. The 'as administrator' option requires you to create a task in Task Scheduler that it uses to bypass the UAC prompt, this task has to be created manually (per the instructions in the included README.txt file).
My solution differs from all the other common methods that let you add such a command because 1/ it avoids the typical 'flashing' of an auxiliary/intermediary window that some people find to be annoying/distracting and 2/ it works regardless of whether the 'Open here' folderpath contains special characters and 3/ it respects user customizations of both (individually) the regular and the 'as administrator' PowerShell windows. For it to work, it also requires you to add the two copies of the shortcuts from the WinX menu in which customizations are stored, i.e. by running the Add_Shotcuts.vbs script, only one time for setting it up.
The scripts also contain some comments to get a clear overview of which files/folders/names/paths they use, to make it easier/faster for you to edit the scripts, should you want to move and/or rename some of the files/folders to suit your own preference.
The only real downsides are that you need to perform a few simple steps to set it up─albeit you only need to set it up one time─and there's a bunch of files there, so it may look a bit overcomplicated as a result. But IMO (and IME) the pros still outweigh the cons anyway, after all.
Ahh I see. Very nice.
Just out of curiosity, did you happen to read the thread in tenforums customization I posted a year ago or so about how to exclude the addition of "open command prompt here" or "open powershell window here" and their elevated analogs to library folders and backgrounds? If you try to open a command prompt or powershell window in a symbolic or hard link (like libraries), nothing happens but the entries created in Directory, Directory, and Drive registry keys add to libraries anyway and there is no obvious way how to exclude. Would you happen to know how?
Thanks
All my scripts work properly for me with all libraries it seems like. The only way that I have been able to get an explorer.EXE error dialog window to appear so far has been after I Shift-Right-click in/on the Libraries (special folder type thing) that appears in the Nav pane of File Explorer. If, however, I go to%AppData%\Microsoft\Windows\Libraries
and I Shift-Right-click in/on that one, all my scripts work normally for me. Special folders are not real folder locations nor are symbolic links. Rather, they merely are visual representations of locations that are concocted by File Explorer itself, to give the fake impression that what you are seeing is an actual symbolic link. I like to refer to these visuals as fata morganas, appearances that occur in the Microsoft-controlled district of the Great Digital Desert. Another example or similar type of behavior, that has also been confusing a lot of people is the Network neighborhood, not to mention the (now gone) HomeGroup fiasco. Unquestionably, these things all have the Midas Touch. My advice? Steer clear from them. If you try the opposite, you'll regret it for the rest of your life.![]()
Understood. If you are interested, here is a link to the thread. There was never a resolution.
How to exclude libraries from custom right-click menu entries
The key is to use some sort of AppliesTo or AppliesTo NOT string in the registry menu entries to exclude the fake Library folders but there is very little documentation on how to use the Strings or how anyone would exclude libraries.
Thanks!
@Brink I saw that there were a number of iterations of this context menu item script. It looked like every topic had been covered, so I was a little surprised to find that there are several characters, that are valid for folder paths, that will result in an error. Those characters are$
,[
, and`
Here are some example folder paths that will error out:
$a b
[a b
`a b
So, I set about to create a one-liner script that could handle all valid Windows folder paths. It turns out to be an almost "you can't get there from here" problem.
At first, the answer seems simple. Just use single quotes around the path and then PowerShell won't expand anything. While that approach will fix the examples above, there will then be the problem that any path with a'
will fail. And I'm sure people use a single quote in folder names at least as frequently as those other characters. So, that's not going to work. And, even though there's the-LiteralPath
option, it doesn't help with the initial parsing of the script.
Edit: Solvable by passing the path via a set command for the non-admin PowerShell, and via the registry for the admin PowerShell. Updated scripts here:
Add Open PowerShell window here as administrator in Windows 10
Last edited by LesFerch; 19 Dec 2023 at 23:17.
I did examine your solution. It's similar to one I've implemented myself and works very well, as long as Windows Script Host has not been disabled and VBScript has not been uninstalled. The version I wrote uses JScript, so it won't be affected in the future by VBScript becoming an optional install or being removed altogether. However, it's still not going to work on machines where WSH has been disabled.
The goal here was to provide a replacement one-liner for the registry that only uses Cmd and PowerShell and will work with any valid Windows folder name.