Re: bin/40080: grep's --color switch won't work with -i option

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR bin/40080; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/40080: grep's --color switch won't work with -i option
Date: Thu, 19 Jan 2017 17:56:31 +0000

 On Tue, Dec 02, 2008 at 12:30:01PM +0000, track.NetBSD%mylists.org@localhost wrote:
  > The --color switch to grep won't work in concert with the -i option
  > if the arg to the -i option is upper-case.
  > >How-To-Repeat:
  > Try these two examples:
  > 
  >   $  echo Dogfood | grep -i --color dog
  > 
  > and:
  > 
  >   $  echo Dogfood | grep -i --color Dog
  > 
  > They both print "Dogfood" for me under both NetBSD 4.0 and
  > 5.0_BETA, but only the first one (using lower case "dog" as the
  > pattern match) shows the color.
 
 (1) This also affects grep -o, except without the "lowercase is magic"
 effect:
 
    valkyrie% echo Dogfood | grep -i -o dog
    valkyrie% echo Dogfood | grep -i -o Dog
    Dog
 
 This is because the "logic" in grep.c for identifying the matching
 part is cutpasted, but only the --color copy includes logic for -i.
 
 (2) The underlying problem is that for some weird broken gnu code
 reason, when it calls back into the matching engine to identify the
 matching part, the matching engine no longer honors -i.
 
 (3) Instead of fixing this, at some point someone introduced a bodge
 into the --color copy of the matching-part code that operates on a
 lowercased version of the matched line when -i is in effect. This
 means that -i --color works as long as the search pattern is
 lowercase, but not otherwise, as observed, whereas -i -o works as if
 -i had been left off.
 
 (4) This crap now lives in external/gpl2/grep/dist/src/grep.c.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost