Jq: ANSI color code 30 clashes with background color

[SWu]

Many terminal emulators can be configured so that the ANSI bold/bright modifier affects the font face only and not color. In these cases, the ANSI code 1;30 results in the same color as background (assuming default dark background color). This means that things like null values in the jq colorized output are not visible.

It would be great to avoid colors 0 (black) and 7 (white) for colorized output to prevent clashing with potential background colors. Even better would be to allow colors to be configurable for jq (similar to ls colors being configured by an environment variable LS_COLORS).

[sjackman]

null is black on my terminal, and invisible with a black background. How about grey instead of black, which would be visible on either a white or black background?

[nicowilliams]

On my terminal (black bg, white fg) null is light gray -- it doesn't stand out, but I do see it.

[nicowilliams]

I guess a separate filter to change colors of output won't be terribly welcomed...

[nicowilliams]

Anyways, should be easy enough. Add a JQ_COLORS env var whose value is a list of eight colors separated by colons or some such.

[nicowilliams]

@SWu @sjackman I'll be pushing this to master soon. If you really need this ASAP, you can try the patch in #1397.

[sjackman]

Thanks, Nico.

I use Terminal.app with the Pro colour scheme. To resolve the issue of invisible null, select Use bright colours for bold text, which is by default, unselected.

[nicowilliams]

@sjackman Did you try the patch and did it work for you?

[sjackman]

I'll wait for the next stable release of jq. I'm pressed for time this week.
Thanks for jq, Nico! It's super useful.

[datfinesoul]

@nicowilliams Thanks for working on this feature. What version of JQ is this going into? I'm on 1.5.2 but don't have this yet, and can't find it in the docs either.

[stephen-dexda]

I hit this too for exactly the same reason as @sjackman. Per https://en.wikipedia.org/wiki/ANSI_escape_code#Colors SGR code 1 is at best ambiguous WRT bold or "bright", so Terminal.app's default behaviour for the Pro scheme (use bold text for that code) isn't wrong.

Would it be possible to use code 90 instead (and maybe similarly for other uses of code 1), to explicitly set "bright" colours rather than an ambiguous bold/bright flag?

[thanatos]

VTE also recently switched the default for bold-is-bright to false, too, so any VTE-derived terminal is likely effected by that now. I concur w/ the comment above: 90 is "bright black", and so if you want to guarantee that null appears in a bold, dark grey, just change the output from \x1b[1;30m (current) to \x1b[1;90m. It'll just work and nobody should have to override settings.

(I'm also of the opinion that this is a good change, as it separates out the bold and bright behaviors into separate flags in the terminal's encoding.)