Colors not working in Powershell env

[killianmuldoon]

Using the Cluster API CLI clusterctl prints the output with color on linux and mac environments, but the same does not work for Windows PowerShell and cmd. The output includes the Raw ANSI codes instead making it unreadable. The current workaround is to set the NO_COLOR env variable to turn off color completely, resulting in a readable, but colorless output.

Is there a way to configure the library to get the correctly colored output on Windows environments?

Related issue: kubernetes-sigs/cluster-api#7381

[pellared]

Are you sure that it is a problem with this library? I am working on Windows and never encountered any problems. I am using this library in https://github.com/goyek/x and I have encountered no issues. Maybe some accurate repro steps? 😉

[pellared]

I reproduced this problem when powershell is called in conhost.exe. I am using Windows Terminal and it works OK. As far as I remember on PowerShell Prompt it works fine as well. https://github.com/mattn/go-colorable works on conhost.exe as well.

So probably the problem is that it is PowerShell inside conhost. Can you confirm? Maybe it is a problem in "PowerShell coloring" design?

[martinlindhe]

It is my understanding that for Windows to properly work with ansi code colors, the application need to signal color awareness thru api:s. If not, color support might be randomly broken between different shells.

fatih/color does not do this setup on Windows, resulting in the same app looking fine in the Powershell Shell or Windows Terminal because they do this setup for every process, but ansi escape sequences are printed while in msys-bash (alongside other apps that properly outputs color by opting in).

The essence of the issue is that in Windows 10 an application need to "opt in" for ansi code support by calling SetConsoleMode() with the ENABLE_VIRTUAL_TERMINAL_PROCESSING bit set.

Here is a better explanation than mine: https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences#output-sequences

I write all of this by experience from previously debugging a similar issue in a rust crate

[martinlindhe]

Sent a PR which fixes the issue on my end.

[GiulianoDecesares]

With version v1.14.1 of this go package, im still experiencing this issue

[martinlindhe]

@GiulianoDecesares this issue is still open, the PR #173 is not merged.

It seems that I accidentally closed the PR, i have reopened it now.

[fatih]

@GiulianoDecesares can you try out @martinlindhe's fix here #173 ?

[GiulianoDecesares]

Yes, Is there any practical way to test this or I just have to download the entire repository and manually replace the references in my code? (I don't know, maybe I can go get the branch in go or something like that) 🤔 @fatih @martinlindhe

[pellared]

@GiulianoDecesares I would try running go get github.com/fatih/color@0b9be245c16cc7838ed7c25db2ec39c6eaa55fbe

[GiulianoDecesares]

@pellared yep! Already tried, but go takes 0b9be245c16cc7838ed7c25db2ec39c6eaa55fbe this as a version and throws an unknown version error

[pellared]

Then probably the easiest way is to

1. clone the repository
2. make the same fix locally
3. use replace in go.mod . more: https://go.dev/ref/mod#go-mod-file-replace

[GiulianoDecesares]

Thanks @pellared for the info on the replace in go.mod. This fix seems to be working fine. Y was able to reproduce it in CMD and then with the replace to a local repo with the same changes, it stops happening. @martinlindhe @fatih

[fatih]

The fix is now released with v1.15.0: https://github.com/fatih/color/releases/tag/v1.15.0