default shortcut on Windows remaps ANSI colors 35,36

[refack]

This should probably go to the Windows group, but Github is a better platform.
Ref: nodejs/node#14243

Steps to reproduce

node
> process.stdout.write(`\u001b[35mXXX\u001b[39m`)

Expected behavior

megenta output

Actual behavior

dark blue output (same as background)

Environment data

The default powershell .lnk remaps colors 35, and 36

[iSazonov]

@refack Thanks for your report! Could you please test with latest PowerShell Core version - Beta.4?

[refack]

Direct execution:

With the shortcut:

The .lnk file
powershel.lnkl.zip

[iSazonov]

@refack Thanks for the test!

[BrucePay]

FWIW - some background: This behavior is actually intentional. Prior to the V1 release of PowerShell, the UI designers picked colors for the PowerShell console. Since the background color they chose wasn't part of the standard palette, one of the less used standard colors was remapped to produce what the designers wanted. It's been shipping that way ever since.

[refack]

FWIW - some background: This behavior is actually intentional. Prior to the V1 release of PowerShell, the UI designers picked colors for the PowerShell console. Since the background color they chose wasn't part of the standard palette, one of the less used standard colors was remapped to produce what the designers wanted. It's been shipping that way ever since.

Designers 🤷‍♂️ .
IMHO should have remapped the black and white, but...
If anyone has any idea how force conhost to respect ANSI, we could implement on our end.

[rkeithhill]

conhost in Window 10 1607 and higher IIRC has some ANSI support. Try:

$E = [char]0x1b; "$E[35;1;40m"

If you're using PowerShell Core then you can use:

"`e[35;1;40m"

It's not 100% though. As I type commands I can see the original blue as the background.

[refack]

@rkeithhill interesting results

Still seems like conhost is using it's own palette, and not ANSI colors...

[rkeithhill]

That ANSI directive is still using one of the 16 palette colors. So if the color palette index has been overridden, you'll get the overridden color. That is why I used the bright magenta e.g.:

If you are on 1703, then you can use 24-bit color:

"`e[38;2;128;0;128;48;2;0;0;0m"

But it only colors output as opposed to changing the bg color.

[rkeithhill]

I don't know about a tutorial but I use as a reference this MSDN page: https://msdn.microsoft.com/en-us/library/windows/desktop/mt638032(v=vs.85).aspx

[gibfahn]

This behavior is actually intentional. Prior to the V1 release of PowerShell, the UI designers picked colors for the PowerShell console. Since the background color they chose wasn't part of the standard palette, one of the less used standard colors was remapped to produce what the designers wanted.

Does that mean there's no chance of it changing? Not being able to see one of the standard colours seems like a pretty major defect for a console (which I guess is why it's remapped in the powershell shortcut, see nodejs/node#14243 (comment)).

IMHO should have remapped the black and white, but...

This seems like a reasonable solution, any chance of it happening?

[silverwind]

Since the background color they chose wasn't part of the standard palette, one of the less used standard colors was remapped to produce what the designers wanted.

I think the default fg/bg colors should be decoupled from the 16 ANSI colors, and instead be separately be defined. That's how pretty much all Unix terminals do it.

[SteveL-MSFT]

As best as I can tell, neither the cmd.exe shortcut nor the PSCore6 shortcut modifies the magenta color so it's only an issue with Windows PowerShell, correct? As @BrucePay mentioned, for Windows PowerShell, this is by-design and changing it now is a breaking change.