Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Null values barely readable on dark backgrounds #1972

Closed
jprupp opened this issue Sep 4, 2019 · 12 comments · Fixed by #2824
Closed

Null values barely readable on dark backgrounds #1972

jprupp opened this issue Sep 4, 2019 · 12 comments · Fixed by #2824

Comments

@jprupp
Copy link

jprupp commented Sep 4, 2019

Description
On Fedora 30, using the default settings on Gnome Terminal (dark background, Tango colorscheme), null values are almost invisible.

To Reproduce
Install a vanilla Fedora 30 distribution.
Install jq from Fedora repositories: dnf install jq.
Display a JSON document with a null value in it.
See how the null value text is barely visible (dark on dark background).

Expected behavior
Every value in the JSON document printed by jq should be clearly visible on any Linux distribution, especially popular ones, and especially using default settings.

Environment

  • Fedora 30
  • jq version 1.6 release 2.fc30 from jq-1.6-2.fc30.src.rpm sources on x86_64
@pkoppstein
Copy link
Contributor

Does the information provided at the following link help?

https://stackoverflow.com/questions/51338701/how-do-i-customize-the-colors-used-by-jq-c

@jprupp
Copy link
Author

jprupp commented Sep 11, 2019

Yes, I can customize colours both in jq itself and the terminal if I need to. The bug report is to encourage fixing default settings rather than dealing with the problem as experienced on my particular setup.

@oryband
Copy link

oryband commented Nov 4, 2020

TLDR If anyone's reading this, setting this environment variable will switch your black bold invisible null to a red non-bold one:

export JQ_COLORS='0;31:0;39:0;39:0;39:0;32:1;39:1;39'

The part affecting this is the initial characters 0;31 which translates to non-bold;red. change 0; to 1; for boldness, change 31 to 37 to make it white and non intrusive.

@oryband
Copy link

oryband commented Nov 4, 2020

Regardless, I also think jq should identify default colors and provide sane defaults. Unfortunate this has to be done manually.

@vijaymarupudi
Copy link

I can confirm that the null does not show up in Alacritty's default colorscheme and the Gruvbox colorscheme in Alacritty and Neovim's internal terminal when using the Gruvbox theme.

@hem-brahmbhatt
Copy link

I'm seeing the same issue on Kitty - Terminal Emulator.

@tleydxdy
Copy link

lol, I was about to make a issue asking why jq prints a empty string to terminal but prints "null" if I have it in a pipe/subshell

@mbeko
Copy link

mbeko commented May 22, 2023

Same here. Although I've been working with Jq for a while, it's only now that I stumbled upon this output where I knew that timestamp is null:

Screenshot from 2023-05-22 16-07-47

I was confused whether this is an issue with Jq or my terminal. I didn't even think that this could be an issue with the default colour because I couldn't imagine that someone would choose black for output in terminals which traditionally have a dark background.

@wader
Copy link
Member

wader commented May 22, 2023

Does non-bold-bright-foreground-black (90) look ok with default colors for kitty, alacritty and neovim?

Can try with:

echo -e '\0x1b[90mnull\0x1b[0m'
# or
JQ_COLORS='0;90:0;39:0;39:0;39:0;32:1;39:1;39' jq -n .

That is was gojq uses. For iterm2 and macOS Terminal.app it looks dark greyish.

@mbeko
Copy link

mbeko commented May 22, 2023

0;90 looks fine for me (Ubuntu 22.04 and Terminator):

Screenshot from 2023-05-22 18-23-24

Side note:
The default value mentioned in the documentation seems to be outdated. If I set JQ_COLORS to that one containing ;37, the white is slightly weaker than without setting JQ_COLORS. The white didn't change however when I used your example with ;39.

❯ jq --version
jq-1.6

@wader
Copy link
Member

wader commented Jun 2, 2023

Found this while poking around #2032 it used to be 39

@mbeko
Copy link

mbeko commented Jun 8, 2023

Ah, I see, 1.6 has been released two years prior to that change and I didn't notice that I was reading the development version documentation. However, the documentation for 1.6 also mentions 37.

In any case thanks for clarifying!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants