Implement a way to enable color in console even when the output is redirected

[ejsmith]

Currently, console color is disabled by checking to see if the console output is redirected or not.

I understand why this was done because there are scenarios that don't support ANSI escape sequences and the output looks really ugly in those scenarios when a bunch of non-rendered ANSI escape sequences are mixed into the output of the CLI.

There is a standard that a lot of other CLI systems use to disable these ANSI escape sequences using an environment variable called NO_COLOR here: https://no-color.org/

This may seem trivial, but when all CI systems like Jenkins, AppVeyor, GitHub Actions and pretty much every single other CI system simply record the redirected console output of the build resulting in a big blob of monotone text and a human is expected to look at that output and quickly identify the issues then it becomes a big problem for usability with .NET Core as a whole.

I am proposing that .NET Core is changed to enable ANSI color sequences by default and that it checks for the NO_COLOR environment variable to disable them.

This issue is being created after a discussion about this topic here: microsoft/vstest#2370

[ejsmith]

Also, I think it is relevant to show what other CLI tools are doing to detect color support in the NodeJS world. Here is the supports-color NPM package: https://github.com/chalk/supports-color/blob/master/index.js

[ejsmith]

Was thinking that the most likely reason why this was introduced in the first place is that, until recently, Windows didn't even support ANSI escape sequences. So maybe this could be implemented as a smart default where it's automatically turned it off on Windows versions less than 10.10586 which is the first build of Windows that started supporting ANSI.

[NickCraver]

I think there are a lot of problems flipped from "default off" to "default on" that would break a lot of systems. I suggest re-titling the issue to be a bit broader to not narrow into a specific fix, e.g. "Allow a way to enable dotnet colorized output, even if console output is redirected". That's really what we're trying to solve - and for .NET that generally needs to be in a non-breaking way.

This could be an environmental variable, or just like on the NO_COLOR site it could be dotnet * --color=true (or whatever is semantically "familiar") as a CLI option...or something else :)

[ethomson]

I think there are a lot of problems flipped from "default off" to "default on" that would break a lot of systems. I suggest re-titling the issue to be a bit broader to not narrow into a specific fix, e.g. "Allow a way to enable dotnet colorized output, even if console output is redirected". That's really what we're trying to solve - and for .NET that generally needs to be in a non-breaking way.

I agree. When the output is not a tty (or "when the console output is redirected") is often because you're writing to a file. You would almost never want inband control characters / ANSI color codes in that output. Running in a CI system is the exception here, not the rule.

You may want to honor NO_COLOR for interactive use - that would be a welcome improvement for people (like me) who started using text consoles before we had these high-falutin' colors and likes it that way. (Also, please get off my lawn.) But NO_COLOR is - as best I can understand - about interactive use, not redirected use / when isatty is false.

For non-interactive use, you really must default to no colors and then opt-in the CI systems explicitly. As a CI vendor, this is what I want and expect you to do for our customers in common.

Mentioned in microsoft/vstest#2370:

I think introducing heuristics similar to Chalk's is quite dangerous as they will become maintenance hell and will effectively turn dotnet into a bottleneck when new CIs are introduced/need to be added.

Yes, this is true. (Though I'd suggest abstracting it out into a separate package.) As a CI vendor, we want to make sure that our shared users have colors. We will take on this burden of contributing support.

[ethomson]

Speaking of a separate package - I'm like 99% sure that cake already has this logic to detect when it's running in CI. Whether that's already abstracted out into a separate package or could be, I don't know, but it may be worth looking there first.

[niemyjski]

I'd think in 2020, we'd be smart enough to detect our environments and show color automatically for a really nice experience instead of opting into it. I don't opt into it in other programming languages, it just works.

Also, the cool kids have color and we need it too 💯

[am11]

For automatic CI detection, here is a list of environment variables from different services:

Variable	Check value	Service(s)
CI	/TRUE/i or 1	TravisCI, AppVeyor, CirrusCI, CircleCI, GitLab CI
TF_BUILD	/TRUE/i	Azure DevOPS
DOCKERFILE_PATH	non empty string	Docker Hub CI
GITHUB_SHA	non empty string	GitHub Actions
JENKINS_URL	non empty string	Jenkins
bamboo.buildKey	non empty string	Bamboo
TEAMCITY_VERSION	non empty string	TeamCity

[ejsmith]

I think there are a lot of problems flipped from "default off" to "default on" that would break a lot of systems. I suggest re-titling the issue to be a bit broader to not narrow into a specific fix, e.g. "Allow a way to enable dotnet colorized output, even if console output is redirected". That's really what we're trying to solve - and for .NET that generally needs to be in a non-breaking way.

I understand that the bar is high for breaking changes in .NET, but not sure that this is actually a breaking change. It would end up being ugly output in the few (IMO) cases where ANSI is not supported. I think it's REALLY important for .NET to have a great experience out of the box for people. The CLI is for developers to use and for developers to look at the output and be able to easily interpret it. I would think that the cases where you wouldn't want ANSI colors are far far less than the cases you do want it. A normal developer is not going to know they need to opt into having color. So we would either need all CI services to agree on some environment variable or we would need the code to check for all of the known CI services which as someone pointed out in the other thread seems pretty hacky and not something that I think the .NET team is going to want in their code.

[ejsmith]

Yes, this is true. (Though I'd suggest abstracting it out into a separate package.) As a CI vendor, we want to make sure that our shared users have colors. We will take on this burden of contributing support.

I am pretty sure that the .NET team isn't going to add a nuget package for something in the core runtime code. So that leaves us with adding code that needs to be maintained to detect all of the known CI services which seems also unlikely that the .NET team would be OK with in the core runtime code.

That is why I think whatever we do it's going to have to be kept simple. Either an opt-in or an opt-out command line flag and an environment variable. I personally feel like it should be opt-out or some sort of smart default.