grep --color=auto with -i option disables the matching text color, why?

Question

I was messing around with grep and put this in my .zshenv:

export GREP_OPTIONS="--color=auto"
export GREP_COLORS='mt=1;34'

I was bonking my head on the keyboard and changing GREP_COLORS around for a minute trying to figure out why the folder colors were working, but the matching text wasn't.

I was doing this:

$ grep -R -n -i -e "functionFoo\(" --include=*.cs --exclude-dir=Logs *

The line number and file names were set with the default colors, but the matching text wasn't.

After spending way too much time, I thought to do this:

$ grep -R -n -e "functionFoo\(" --include=*.cs --exclude-dir=Logs *

(I removed the -i option.) That's all it took to get the matching text to correctly show up in bold blue. This is a Cygwin on Vista setup, with rxvt running zsh.

Any idea why grep colors would break on specifying a case-insensitive match?

Update: Under cygwin 1.7, it's a little bit better - case insensitive search works correctly, but it only highlights the word that matches the expression exactly. In other words, "FunctionFoo" highlights "FunctionFoo" but not "functionFoo" and vice versa. Probably a grep issue so I'll be submitting it to that list.

• innaM: This works for me using GNU grep 2.5.4
• quack quixote: works for me, GNU grep 2.5.3, under bash on debian lenny and on cygwin. what version grep? what system?
• emptyset: GNU grep 2.5.3, and CYGWIN_NT-6.0-WOW64 AAF 1.5.25(0.156/4/2) 2008年06月12日 19:34 i686 Cygwin is the uname -a output.
• quack quixote: i've got the same buildtime on my cygwin but it's CYGWIN_NT-5.1 (on winXP here). my best guess is you're hitting some bug in cygwin .. likely some difference in XP-cmd.exe vs Vista-cmd.exe that hasn't been addressed properly in cygwin's terminfo/termcap. you should probably drop a bugreport to cygwin about it.

Answer 1

This is not related to Cygwin but to grep. You need to set the locale environment variables in your shell, like LANG.

Taken from the grep(1) manual:

The locale for category LC_foo is specified by examining the three environment variables LC_ALL, LC_foo, LANG, in that order. The first of these variables that is set specifies the locale. For example, if LC_ALL is not set, but LC_MESSAGES is set to pt_BR, then the Brazilian Portuguese locale is used for the LC_MESSAGES category. The C locale is used if none of these environment variables are set, if the locale catalog is not installed, or if grep was not compiled with national language support (NLS).

Try for example:

LANG=en_US.UTF-8 grep -R -n -i -e "functionFoo\(" --include=*.cs --exclude-dir=Logs *

That should fix your problem, and works for me with GNU grep 2.5.4 and bash 3.2.48(1)-release.

• emptyset: Almost works. When I set the shell variable inline like that, it works if LANG is currently set to C.UTF-8 (default). When I edited my .zprofile to include the line export LANG=en_US.UTF-8, then it ceases to work (even setting LANG inline).
• sirdharma: What version of zsh are you using ?

Answer 2

I had this same problem using Msys MinGW. I didn't find a way to resolve it so ended up using:

ack -i PATTERN

which does colors and case insensitivity correctly.