Add possibility to write ANSI color escape codes when the console output is redirected

[0xced]

This introduces an opt-in mechanism to allow writing ANSI color escape codes even when the console output is redirected.

To enable ANSI color codes, the DOTNET_CONSOLE_ANSI_COLOR environment variable must be set to true (case insensitive) or 1.

Fixes#33980

[ghost]

Tagging subscribers to this area:
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This introduces an opt-in mechanism to allow writing ANSI color escape codes even when the console output is redirected.

To enable ANSI color codes, the DOTNET_CONSOLE_ANSI_COLOR environment variable must be set to true (case insensitive) or 1.

Fixes #33980

Author:	0xced
Assignees:	-
Labels:	area-System.Console
Milestone:	-

[ejsmith]

Nice! Thanks for doing this!

[stephentoub]

Direction for #33980 needs to be resolved first. @KathleenDollard, please chime in.

[ethomson]

I'm sorry, but I must still disagree that this is the correct direction. CI providers already have a standard mechanism that they use to communicate that you're running in a CI environment. For better or worse, this is the status quo; tools detect the CI environment and adapt their behavior accordingly.

By introducing a novel variable, that means that you're expecting the CI systems to start setting it.

I don't mean to sound negative or difficult, but we will not, if for the practical reason that there are many more applications in the world than there are CI systems and there's already an established mechanism where the apps check to see if they're running in CI. We simply can't set dozens or hundreds (or more?) of environment variables.

(I apologize if your change is orthogonal to CI systems, but that was certainly my interest in and understanding of #33980.)

[0xced]

I apologize if your change is orthogonal to CI systems

Yes, this change is absolutely orthogonal to CI systems. The modification proposed here is at the Unix Console platform abstraction layer and should certainly not have anything remotely related to CI environment variables.

By the way, I just rebased on the main branch and I'm waiting for directions before tackling the cache the environment variable evaluation in a static reviewed by Stephen.

[jeffhandley]

Since #33980 still has some open topics, I'm going to mark this PR as a Draft until those details are solidified.

[ghost]

Draft Pull Request was automatically closed for inactivity. Please let us know if you'd like to reopen it.

[0xced]

closed for inactivity

☹️

[ejsmith]

Pretty damn sad. This seems like a really nice thing to have and an easy win.

[stephentoub]

@0xced, I pushed a commit to your branch that:

• Changes the env var name
• Also adds NO_COLOR
• Caches the result in a field to avoid getting environment variables every time we're writing out
• Adds a test for the env var

@dotnet/area-system-console, please review.

[ejsmith]

@stephentoub this looks good. Thank you! My only question is if converting the stored int to a bool on every single console write would be a perf hit over just storing the calculated bool value?

[stephentoub]

Thank you!

You're welcome.

My only question is if converting the stored int to a bool on every single console write would be a perf hit over just storing the calculated bool value?

No, it won't be measurable. It's just value != 0. It's also not on Console.Writes, just color changes.

I do need to delete an erroneous assert that's the cause of the test failures.

[tmds]

@stephentoub when TERM is not set and DOTNET_CONSOLE_ANSI_COLOR is set, no color codes are written because TerminalFormatStrings are null.

[stephentoub]

when TERM is not set

Thanks. I can fix the test for when in CI for that. I don't think there's a product issue here, though; if you don't have TERM set, you can set it. Agreed? Or is there a larger concern I'm not aware of?

[tmds]

Thanks. I can fix the test for when in CI for that. I don't think there's a product issue here, though; if you don't have TERM set, you can set it. Agreed? Or is there a larger concern I'm not aware of?

Yes, it can be set. I don't know if it is expected to be set in the CI environment variables DOTNET_CONSOLE_ANSI_COLOR is meant for.
Alternatively, fixed literals can be used (as in AnsiParser.cs).