Not sure when this started happening or what I may have changed to trigger it - or even if it's just a cosmetic thing or not, but:
On my Location bar, I've got a triple-button that does 'cli dosprompt' or 'cli dosprompt=admin' for left/right mouse click...
The admin prompt causes the UAC prompt to request elevation as expected...
The 'regular' dosprompt button does not (also as 'expected'), but the console window that opens has the same reddish hue to it that the admin prompt does.
Looking at taskmgr, it's clear that one cmd task is prepended with "Administrator:" and the other is not. So, I'm not super concerned about this being any sort of security issue... really just want to understand why the console display appears the way it does and how I might change it to standard black. Running cmd from any standard windows shortcut or from Start->Run results in a "normal" black console window. It appears to just be happening with command prompts launched from within Opus - i.e. the same thing happens even if I just run cmd.exe directly, from the FAYT / command field (as opposed to using Opus' raw CLI dosprompt command).
The red colour isn't an inherent indicator of an admin command prompt, it's just something that Opus tells cmd.exe to do when Opus launches an admin command prompt.
(i.e. If you launch an admin command prompt via some other method, it won't always be red.)
When you open a non-admin command prompt in Opus (or any type of command prompt via any other method, assuming no colour is specified on the command-line), then the colour used should be whatever you have saved as the default via the command prompt's Properties dialog. (Or the default colours if you have never gone in there and changed them.)
When you modify a command prompt's properties it will prompt you to ask if you want the same changes to be remembered for all future windows like the one you opened, and I suspect you did that at some point (from a command prompt Opus had opened with red text). I'm not sure of the exact rules that are used to decide that a command prompt should use those settings, but if you modify them again from the window with the wrong colours and save them, I'd expect that to solve the problem.
Right - I realize the red tint is just an "indicator", and taskmgr certainly soothed any concern that the non-admin prompt was somehow elevated.
That said... your comments about saving command prompt properties is behavior I'd always known and seen in WinXP, and it always happened in two distinct ways:
prompted to apply changes to the shortcut that launched the command prompt
prompted to apply the changes next time that same location is opened to a command prompt (i.e. system32 from a typical start->run launch of cmd.exe, etc).
Either way, though I have indeed made and applied changes (quick edit and window size) I hadn't ever set the background color to anythign particular. But, launching a non-admin prompt from Opus, and then setting the BG color back to black solved it - so thanks for the suggestion.
A short note for anyone who later reads this and hadn't known that you can change the color of the command prompt: this is one of DO's great little gifts.
For instance, here's the command you'd put in a button for a non-admin command prompt in light aqua on a blue background. Love that look.
CLI DOSPROMPT="noadmin,color=1B"
For the admin version, change noadmin to admin.
For the table of possible colors, see the CLI page in the Opus manual and scroll down two shakes to the DOSPROMPT section.
For the record - while I certainly hadn't "intended" to set the color for the normal non-admin prompt, I think what must have happened is that when I went to save my "other" preferred changes (quick edit and window size), I must have done THAT from an admin elevated console prompt. So when I saved those settings, the background color Opus launched that elevated console with then also got saved for non-admin console windows as well. Oddly, it only applied to prompts launched via Opus. All other shortcuts and start->run executions of cmd opened normally.