Colors not working in Powershell env

Question

Colors not working in Powershell env

killianmuldoon opened this issue 2 years ago · 13 comments

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

Answer 1 · 2022-11-14T22:47:15.000Z

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? 😉

Answer 2 · 2022-11-14T22:53:46.000Z

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?

Answer 3 · 2022-12-03T01:01:36.000Z

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

Answer 4 · 2022-12-03T01:49:31.000Z

Sent a PR which fixes the issue on my end.

Answer 5 · 2023-02-23T16:03:26.000Z

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

Answer 6 · 2023-02-23T17:59:05.000Z

@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.

Answer 7 · 2023-02-26T08:39:16.000Z

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

Answer 8 · 2023-02-27T12:43:00.000Z

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

Answer 9 · 2023-02-27T13:04:58.000Z

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

Answer 10 · 2023-02-27T13:12:22.000Z

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

Answer 11 · 2023-02-27T13:15:39.000Z

Then probably the easiest way is to

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

Answer 12 · 2023-02-28T17:11:26.000Z

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

Answer 13 · 2023-03-12T11:27:52.000Z

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