I see in the tools menu there are 2 shortcuts to command prompt here (also, any way to set it so the admin window isnt red? i find it quite hard to read). Is it possible to have some extra items in the tools menu? such as
Launch Powershell Here
Launch Powershell Here (Administrator)
Launch Powershell ISE Here
Launch Powershell ISE Here (Administrator)
it would save me a lot of time if this were possible 
Thanks
Open PowerShell Here has one way to do it.
The CLI command has arguments for changing the normal Command Prompt colors.
Editing the default Tools menu is possible in Opus Pro.
If you're using Opus Light, the default menu is not editable but you can add additional toolbars and/or hotkeys for custom actions (single-line commands only).
This is my Powershell HERE command. I looked the other threads, looked very complicated to set up? This is all in one line, also changing prompt to be dual line whilst adding time and user information. Maybe you can make use of it.
powershell.exe -noexit -command "&{cd '{sourcepath}'; $env:CurrentDirectory='{sourcepath}'; function global:prompt {''+(gl).providerpath+' - '+(get-date -uf %H:%M:%S)+' '+$env:username+[char]10+'>'}}"Results in a regular powershell window and prompt like this:
[code]D:\bin\file\dopus - 09:10:03 Administrator
[/code]
We're adding a proper "PowerShell Here" command in the next update (12.2.6), and also including it in the default toolbars.
e.g. CLI DOSPROMPT=powershell is all you would need to open PowerShell.exe in the current folder.
or CLI DOSPROMPT=powershellise for the ISE version.
I'm on Win10 Pro - haven't had the Anniversary Update very long. I have just noticed that in my DOpus 12.3 x64, under the Tools menu, both 'Command Prompt Here' items are grayed out. I have set up a right-click context setting to get a command prompt with admin rights, but am puzzled at the Tools menu. If I go into Settings -> customize for the Tools Menu I see that both Command Prompts (one with admin rights and one without) are there, but I don't know how to make them stay active once I'm out of Customize.
That probably isn't very clear - sorry!
How can I restore the expected behaviour under the Tools Menu?
Thanks.
Please re-download 12.3 and it should be fixed.
Leo - That was a very surprising answer, but it did indeed fix the problem. Thank you very much.
John
I 'factory reset' my Toolbars and now can see the new 'PowerShell Here' commands in the Tools menu. Nice, thanks.
I could not see how DO sets the Background/Foreground colours for these? The Edit command shows only the CLI DOSPROMPT command with the 'admin' and new 'powershell' options but without the 'color=nn' option?
I can over-ride by adding the 'color' option (and surrounding all the options with quotes as suggested in the CLI link you provided above).
But how does DO set the colours for the DOS Windows?
It sends commands/arguments to the PowerShell or cmd.exe to tell it which colors to use.
You don't need to do that yourself, though. You can change the colors by adding the color=nn option to the command. Details are in the page documenting the CLI command.
How weird, I seem to have a colour mismatch when using the DOSPROMPT 'color=nn' option between the CLI and PowerShell Windows? I set both Admin windows to be 'color=5F' and the PowerShell comes out a dark blue rather than purple? My '1F' color windows look similar, but 5F are very different? Is this just my own setup/monitor, or is it everyone?
See screenshot of '1F' and '5F' DOS/PowerShell windows (four windows in centre of screen). The left top is the PowerShell '1F' window, bottom left is the DOS '1F' window. Top right is PowerShell '5F' window (? looks blue to me), bottom right is the DOS '5F' window. All are 'admin' windows. I prefer the darker blue to the purple actually, but why is there a mismatch for the same color value?
Command Prompt and PowerShell both use 16 colors defined via their settings dialogs:
(PowerShell has names for the colors, like "red" etc., but they are actually wrong, as each name just maps to a color index number, and the default colors changed a long time ago. So you have to work out which color index you are using, then work out which name maps to that index (which isn't documented!), then specify that name, even though the name may have nothing to do with the actual color. God knows why they used indexed color for something invented in the last 20 years, then used names, then let the names go wrong without updating them... Or, really, why they made PowerShell use the ancient command prompt host in the first place... PowerShell generally solves all the wrong problems, makes a bunch of things worse, and does very little to solve the real issues that the Windows command prompt has always suffered from. On top of that, it made the much more useful JScript/VBScript ActiveScripting become relegated to a legacy component, despite the fact it does things PowerShell still can't do, and could do everything PowerShell does if expanded a bit. It's a crying shame.)
I'm running 12.4, is it just me or does CLI DOSPROMPT=powershellise end up just launching a normal powershell on the relevant path?
Is there any plans for an elevated option?
CLI DOSPROMPT=powershellise,admin
It opens PowerShell ISE for me here, at least. Opus 12.4 and up-to-date Windows 10.
That already works (at least here).
Questions:
Does PowerShell ISE work on your machine if launched via the start menu?
Is it in the standard path? C:\Windows\system32\WindowsPowerShell\v1.0\PowerShell_ISE.exe
Thanks for the prompt response Leo, I'll check and get back to you tomorrow. Sounds like it is an issue on my side somewhere. Cheers.
So, ISE (for what it's worth, I'm referring to ISE as opposed to ISE x86) details as per my working shortcut are -
Target:
%windir%\system32\WindowsPowerShell\v1.0\PowerShell_ISE.exe
(%windir% is indeed C:\Windows)
Start in:
%HOMEDRIVE%%HOMEPATH%
So yes, when launched from that shortcut, it works (and a right click, run as administrator also launches an elevated Powershell ISE correctly).
EDIT: I just realised that it was Quick Access Popup (http://www.quickaccesspopup.com/) that was stuffing up the middle click for ISE, so disregard the ISE issue, it works fine with QAP disabled. Apologies for wasting your time on that aspect!
So the only outstanding issue I can see is that when you try and launch an elevated variant of either ISE or Powershell using CLI DOSPROMPT=powershell,admin or CLI DOSPROMPT=powershellise,admin it will open on the local system path (PS C:\WINDOWS\system32>) all the time if you attempt to launch it from a folder on a UNC path. By comparison, the non-elevated variants detect the UNC path and launch correctly on the UNC path. The elevated variants launch correctly on local paths rather than the system path too (I haven't tested mapped drives as yet).
You could try running it manually. All the command really does is run the program and pass an argument for the current path to it, or change the current folder path before launching it (for ISE, since it lacks a proper way to tell it the path to use or a command to run; ISE is extremely limited in terms of command-line options, ironically).
Thanks Leo, as per edit above, the ISE aspect was indeed my problem, sorry for the Red Herring there. Any thoughts on the UNC issue with an elevated shell/ISE?
It works OK with UNC paths for me, at least the one I'm trying that is mapped with explicit credentials (not pass-through authentication).
Newer versions of Windows do not pass mapped network drives through to elevated contexts by default, but I think that would only matter if you were using a mapped drive letter, not a UNC path.
Maybe something else on your system is causing problems?
What happens if you try to do it manually, without Opus being involved?
Thanks Leo, sounds like that issue might be on my side as well then. I'll have a play around and get back to you.
