Remove color parsing from Coreclr on Linux and Mac

[BrennanConroy]

#1708

[victorhurdugaci]

I don't think parse is the right term here. Maybe useColors or something on those lines would be more appropriate

[victorhurdugaci]

Looks good overall, except the places where I commented.

[BrennanConroy]

@victorhurdugaci
Made changes, take a quick look?

[victorhurdugaci]

Naming convention for fields: _camelCaseName

[victorhurdugaci]

looks good.

[moozzyk]

Designwise, I don't think we should cache _output and _error here. These are static field and the value depends on runtimeEnv. It will probably work fine now if runtimeEnv does not change but if for whatever reason GetOutput() was called multiple times with different runtimeEnv value the returned value for the second call would be wrong because it would use runtimeEnv from the first call. I think the GetOutput and GetError should just create and return the value and the code that invokes these methods should take care of caching the returned instance if it makes sense.

[BrennanConroy]

@davidfowl
Is this more like what you want?

[troydai]

Format: space after if

[troydai]

after format the code.

[moozzyk]

Agree with @davidfowl that useAnsiCodes sounds weird but otherwise 🐑🇮🇹

[BrennanConroy]

He suggested useAnsiCodes >.>

[davidfowl]

Why is the build failing?

[glennc]

This name doesn't feel right. You are using ansiCodes either way, just processing them differently. It is more like ansiCodePassthrough, but given that nobody knows what that means and this is internal it doesn't worry me too much.

[glennc]

This changes the behaviour of this does it not? Previously everyone who called this would've gotten the same instance. Now they will all get a different one. Not sure it matters, but it is a thing. @davidfowl?

[davidfowl]