Terminal: Can't change background color in Powershell after updating to 1809

[johanlindfors]

After the latest update to Windows 10 1809 I can't change the background color of the PowerShell console from within the actual console.

This used to work:

Clear-Host
(the window was now black)

But it doesn't anymore.

[zadjii-msft]

I'll take a look at it. There's a good chance I regressed this. Internally filed as MSFT:19234722

[bitcrazed]

Thanks for filing @johanlindfors.

@zadjii-msft - I created bug 19221878 to track this.

[DHowett-MSFT]

[Linking] This was also reported at lzybkr/PSReadline#774.

[lzybkr]

This happens because PSReadLine is writing CSI 0 m, you can reproduce w/o PSReadLine like this:

function prompt { "PS> " } # Ensure we aren't using posh-git
[Console]::BackgroundColor = 'Yellow'
cls
"$([char]0x1b)[34mHello$([char]0x1b)[0m"
"$([char]0x1b)[34mHello$([char]0x1b)[0m"

After the cls, I have the follow

So it looks like writing CSI 0 m reverts the background color to the initial background color, not the current background color (which may have been set via an escape sequence or via a Win32 Console api).

It also looks like this behavior is not specific to conhost, I see the same thing in the CentOS Terminal.

So is it safe to say that any tool that writes CSI 0 m should save the current foreground/background colors before writing anything and restore them afterwards? Assuming this is correct, Posh-Git and maybe Powerline also need to be fixed.

[mjoyce6500]

Experiencing same issue after OS update. Custom $PROFILE which was working now reverts back to system default background color at the prompt as you type ….

[miniksa]

This was moved to Powershell as MSFT: 19221878 to track an inbox release. It has been fixed in PSReadLine on GitHub according to @SteveL-MSFT.

[DHowett-MSFT]

I never really weighed in on this, but I'd like to double-click on this:

So is it safe to say that any tool that writes CSI 0 m should save the current foreground/background colors before writing anything and restore them afterwards?

• @lzybkr

I think it's unsafe to say that. We're moving to a world where the user's current foreground/background color is a non-machine-manipulable user preference, and one that cannot be represented by an index into the standard color table.

If the user's "default" colors aren't the same as their current runtime colors, that is a user configuration issue. No tool should try to divine what the background and foreground are, because those colors may not be representable in any known color space. Attempts to do so (like PSReadline here and MSYS/MinGW/Cygwin for git) result in a poor user experience.

The correct solution is that any tool that would like to play nicely with other tools _and terminals_ should use CSI 0 m to mean "restore your default colors." It was a mistake to allow commandline applications to know the "active" and "default" colors.

[lzybkr]

@DHowett-MSFT - I like the idea that user color preferences are more static. I'm sure you're well aware that configuration of said preferences needs to be easy though, as easy as what folks do today in their PowerShell profile.

I do think that we need to make it easier for colorful command line applications to choose appropriate defaults though. Today if you use a white/light background, PSReadLine is essentially unusable. This is only fixable if you can query the RGB value of the background - which you can do with a Win32 api or some terminals with the appropriate VT sequence.