Controlling the output terminal colors

[chriscroome]

I have a terminal set to white on black, ansible-lint warnings are black on black, I have this in ansible.cfg to fix an issue like this with Ansible itself:

[colors]
debug = blue

But I can't work out how to set the ansible-lint warning colour, can someone explain how this can be done?

Originally posted by @chriscroome in #4461

Discussed on the Ansible Forum in https://forum.ansible.com/t/how-can-the-ansible-lint-warning-colour-be-controlled/39511

[MindTooth]

This was not an issue before. So is the change to remove Rich causing this?

[chriscroome]

Sorry I don't know what Rich is but I have only recently noticed this issue, I haven't tested with older versions to see if these have the issue but could, do you know which version should I roll back to for testing?

[MindTooth]

#4396

They refactored out Rich which I assume provides the colors, etc. So now that it's out, we have black on black. Which for me is a bug/regression. 😔 I hope that explained it.

ansible-lint==24.10.0 works for me and now prints gray which is visible. I have only code from work and can't show it.

@ssbarnea I see you made the pull request. Thoughts?

[osiris]

Hi @ssbarnea in ansible-lint==v24.12.2 the black on black error persists!

[aphedges]

For anyone that needs a workaround, @chriscroome noted in the original forum thread (https://forum.ansible.com/t/how-can-the-ansible-lint-warning-colour-be-controlled/39511/3) that one can disable the unreadable colors with --nocolor. That change was enough to allow me to upgrade.

[ssbarnea]

Yes, removal of rich does change the way we produce colors but was not supposed to produce such undesirable outcome. 99% of users as using white on black anyway, including myself. I do suspect that your terminal might be missing some features that we use and that is why we see this problem.

Can you please try several terminals in order detect why you get this behavior?

Note that we do not have a plan to implement any feature to allow customization of colors (at least yet), but we will try to fix the output to make it readable. We only need a way to reproduce it. Maybe running an ANSI test with your terminal might uncover which ANSI extensions are not implemented by it?

[MindTooth]

Here is from both Terminal.app and kitty:

In contrast to 24.10.0:

[chriscroome]

I'm also using Kitty, which is, of course, installed using Ansible! 😉

[aphedges]

Can you please try several terminals in order detect why you get this behavior?

I'm using macOS, and I get the unreadable text in PyCharm 2024.3.1.1 (top) but not in iTerm2 3.5.11 (bottom). I've encountered various other problems with colors in PyCharm's terminal, so I wouldn't be surprised if there is a bug in the terminal itself, not ansible-lint's code.

Maybe running an ANSI test with your terminal might uncover which ANSI extensions are not implemented by it?

Do you have recommendations for one to run? That seems like a useful tool to help with terminal problems like these.

[chriscroome]

With the Debian Bookworm Gnome terminal I get black-on-black and unlike with Kitty the text doesn't even show up when highlighted:

gnome-terminal --version
# GNOME Terminal 3.46.8 using VTE 0.70.6 +BIDI +GNUTLS +ICU +SYSTEMD

With Foot I get just-about-readable grey on grey:

foot --version
foot version: 1.13.1 +pgo +ime +graphemes -assertions

So perhaps it is a client issue? 🤷

[chriscroome]

Does anyone have a minimal bit of code to generate the black-on-black output? I was thinking of raising this as an issue with Kitty but I'd need the simplest method of generating the error to do this.

[ssbarnea]

Run with FORCE_COLOR=1 and redirect to file to capture our own ansi output. isolate one broken line, decode ansi codes to identify if is a terminal bug or we do send bad output with very low contrast.

easy to test the captured output with other terminals

[chriscroome]

Thanks @ssbarnea I have started a discussion about this on the Kitty forum.

The code in question is \033[1;30m and this is listed here as bold black, this is how it is rendered by Kitty, so I'm not sure why people think it is a client issue? Unless it is expected that clients invert the text colour when black-on-black is detected?

[chriscroome]

The developer of Kitty is of the view that:

I didnt look at the dump file but this is obviously a client issue. The
terminal emulator simply uses whatever colors the client tells it too.
One thing the client should make sure of is that it is not using bold to
get bright colors, instead it needs to use colors from 8-15 for the
right versions of colors from 0-7.

[MindTooth]

Since I'm using Srcery and based on the comment made from Kitty, I did check the scheme. What I found is that the color black is the same as the background, so black-on-black.

From https://github.com/kovidgoyal/kitty-themes/, I can see a lot of the original themes too have black-on-black, which could explain this phenomena.

I will look more into this at least for Srcery, and it's something to have in mind for other schemes as well.

[aphedges]

Given that this bug appears on 3 out of 4 terminals tested, I feel the fix should probably be made in ansible-lint itself.

I'm not saying we should go back to using rich, but rich was clearly doing something that avoided this problem.

[ssbarnea]

I does reproduce with Fedora (40) with default terminal and shell (bash) so is clearly a serious bug. We need this fixed and releases ASAP.

[chriscroome]

I'm happy to say that I do now have visible warning with 25.1.1 however that's all I have due to this issue!

[osiris]

Hi @ssbarnea, I confirm that the black on black error was solved in ansible-lint==v25.1.1
Tested at Terminator 2.1.2 in Debian 12