Closed dserodio closed 1 month ago
What do these values show?
$ echo $TERM
$ echo $COLORTERM
$ echo $NO_COLOR
Option --color
(--color=auto
) checks if the TTY supports color when displaying on TTY, whereas --color=always
overrides this. It's similar to how GNU/BSD grep check for TTY color.
$ echo $TERM
xterm-256color
$ echo $COLORTERM
truecolor
echo $NO_COLOR
For some reason, grep
(BSD, macOS default) doesn't use colors by default either, but grep --color
and grep --color=auto
do.
For ug
, even --color=always
doesn't use colors
Well, I installed ugrep with Homebrew to check this out, but colors show up fine. Tried with different shells bash, zsh and tcsh to make sure. Perhaps you've changed a .ugrep file to somehow disable colors or add tag
to use non-color text tagging of matches.
My comment above is not meant to ignore your question and concern, but I have absolutely no idea why and how this can happen. Try ugrep
which does not read a .ugrep file. The NO_COLOR
environment variable should be unset or if it is set then it should have no value. If it has a value, then colors will not show,
Don't worry, I didn't feel ignored, but I have no idea why this is happening. I normally use iTerm2 with zsh (both heavily customized), but I just tried with Terminal.app with a plain bash shell and still no colors. 🤔
I don't have a .ugrep
file and NO_COLOR
is undefined
$ if test "$NO_COLOR"; then
> echo "NO_COLOR=$NO_COLOR"
> else
> echo undefined
> fi
undefined
The --color=always
option overrides environment variable settings and output redirects, except when --tag
is used.
Try this: ugrep --color=always --colors='ms=hr'
to force match color highlight red.
Colors are also affected by the grep environment variables GREP_COLOR
and GREP_COLORS
when set.
Nailed it! 🙌🏼 ugrep --color=always --colors='ms=hr'
works!
So I checked that GREP_COLORS
is set to 1;32
. If I unset it, both ugrep zsh /etc/shells
and ug zsh /etc/shells
highlight as expected, so the issue seems to be the way ugrep parses this value
I will add a check in the code for this to allow 1;32
without the usual name=value parameter pairs such as mt=1;32
. I had already included logic in the code to parse the deprecated GREP_COLOR
that is a short form like 1;32
, but GREP_COLORS
is expected to contain a list of name=value parameters.
Seems logical then to also allow --colors='hg'
to set mt=hg
without specifying mt=
, i.e. highlighted green matches (and you can also use --colors='1;32'
of course).
Thanks so much with your patience troubleshooting this.
My dotfiles are ancient (I started versioning them back in CVS around 2005) so I have no idea where this 1;32
syntax came from. I just removed GREP_COLORS
from by dotfiles. Feel free to close this issue now or when (if) you implement the check for this ancient syntax.
Thanks again!
I've update the dev version and plan to release minor patch update 6.1.1 soon.
Released 6.2 with updated legacy grep color support.
I can't get
ug
to use colors, even when explicitly using--color
. It was installed on Mac using Homebrew