CLI (permanently) changes console color when an invalid command is typed

Steps to reproduce

Try to use a command that doesn’t exist. e.g.: dotnet.exe migate

Expected behavior

An error message appears, maybe in a different color, and then console color is unchanged after that.

Actual behavior

Console color remains pink-ish.

Environment data

.NET Command Line Tools (1.0.0-preview4-004129)

Product Information:
 Version:            1.0.0-preview4-004129
 Commit SHA-1 hash:  325b849858

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   E:\Tools\dotnet-dev-win-x64.latest\sdk\1.0.0-preview4-004129

[reecebradley]

Greetings! I’ve worked in a way to fix this issue, however, I’d like to explain what the issue is here first.

The Problem

Given the example above, here is the same example in the easiest way to explain it:

<OriginalConsoleColor>
dotnet foo
<Bold><Red>No executable found matching command "dotnet-foo"<OriginalConsoleColor><NotBold>
C:\Users\scott>

Each tag represents a ForegroundColor change. The real issue is in AnsiColorExtensions

        public static string Bold(this string text)
        {
            return "\x1B[1m" + text + "\x1B[22m";
        }

The marker 22m turns off bold - according to the AnsiConsole.Write.

If you look at the color extensions:

        public static string Red(this string text)
        {
            return "\x1B[31m" + text + "\x1B[39m";
        }

They all use 39m which translates to setting the console foreground back to the original color before the program started.

Summary

Since Console.ForegroundColor is static, whatever the last state this value is set to when the program ends will be what the user sees. Therefore, anyone who uses the AnsiColorExensions.Bold() last as in the case of the error message, the result is what you’ll see in the original post.

Possible Solution

I’ve gone through a few variations of fixing the issue and through that process I see a flaw with the AnsiColorExensions and AnsiConsole. Mainly that we cannot assume the <OriginalConsoleColor> is either <Bold> or <NotBold>. So using any actual color (excluding bold) in the AnsiColorExensions will result in writing a message out to the Console using the original color which could be a Bold or NotBold color, maybe that was intended? And using the Bold() extension was to ensure that the color would in fact be bold? The fact that color and boldness are not two different properties of the console complicates what is trying to be done. You have Green and DarkGreen, no property for bold.

That said, this is one of the ways to fix this:

        public static string Bold(this string text)
        {
            return "\x1B[1m" + text + "\x1B[39m";
        }
        public static string NotBold(this string text)
        {
            //This is the default but this option forces console windows
            return "\x1B[22m" + text + "\x1B[39m";
        }

Going back to my earlier statement, the original color of the Console.ForegroundColor could be a bold or not bold color, maybe you want to ensure text will in fact be NotBold? In which case, the above changes will be explicit.

I have those changes and others to support it in my fork for your viewing. I was about to make a PR, but due to design changes and get feedback there, but it seems maybe discussing it here is better.

Hopefully this all makes sense!

Reece

[reecebradley]

Watched the community stand-up - interesting background on how this bug really ‘BUGGED’ @shanselman 😉 Always interesting listening to community stand-ups, keep up the good work!