Re: Bug#582083: patch for grep --color to non-tty output

[Jim Meyering]

Tim Connors wrote:
> On Tue, 24 Apr 2012, Jim Meyering wrote:
>
>> Aníbal Monsalve Salazar wrote:
>> > Debian bug report is posted at:
>> >
>> > http://bugs.debian.org/582083
>> ...
>> >>There's no reason not to obey the user when they ask for "--color",
>> >>regardless of whether the output is to a tty or not.  They wouldn't
>> >>have asked for --color if they didn't want it, and most other gnu
>> >>programs assume --color=yes rather than --color=auto when supplied with
>> >>just --color.  Man and info pages and translations appear to need to
>> >>work since they don't imply what the default is.  Nice easy patch to
>> >>apply!
>> >>
>> >>[1] New version looks like:
>> >>diff -ru grep-2.10//src/main.c /tmp/grep-2.10//src/main.c
>> >>--- grep-2.10//src/main.c       2012-04-24 13:11:57.000000000 +1000
>> >>+++ /tmp/grep-2.10//src/main.c  2012-04-24 12:56:47.000000000 +1000
>> >>@@ -2059,7 +2059,7 @@
>> >>           else
>> >>             show_help = 1;
>> >>         } else
>> >>-          color_option = 2;
>> >>+          color_option = 1;
>> >>         if (color_option == 2)
>> >>           {
>> >>             char const *t;
>>
>> Thanks for the report of the documentation bug and the patch, but the patch
>> (changing the meaning of --color from --color=auto to --color=always)
>> would break existing usage.
>>
>> Currently, people can use --color in an always-on alias/function
>> or set the GREP_OPTIONS=--color envvar and get colorized output,
>> yet not have those ANSI terminal highlighting bytes interfere
>> with output that is not to a tty.
>>
>> If we were to make your proposed change, they'd find those
>> color codes in unexpected (and undesirable) places.
>
> Easy to fix!  Fix the bug in their login scripts!

If it were only in dot-file alias/function definitions,
it'd be an easier call.  Are there uses of grep --color
in other contexts?  Probably.

>> However, this is definitely a documentation bug, and I'd
>> appreciate a patch for both --help and grep.texi.
>>
>> Jim
>>
>> PS.  True, it is undesirable to have grep's --color(with no value)
>> default to "auto", when in ls it defaults to "always", but changing
>> grep's default now would be too disruptive.  We'd have to warn that
>> the default is going to change for a year or two before making the
>> actual change, and even then, some users would be impacted.

If you know me, you know that the above is just this humble
maintainer's opinion.  If enough people chime in saying that they
think making grep --color align with ls --color behavior is important,
and that they think the risk to existing users is low enough,
I'll be happy to reconsider.

> It doesn't take much to change one's .rc files to say
> GREP_OPTIONS="--color=auto" rather than "--color"!  They should have been
> doing that all along (because they were relying on undocumented behaviour
> :).
>
> I personally have "GREP_OPTIONS=--color=auto".  If the output is a tty,
> that works as expected.  If the output is a pipe, no color as expected;
> all good.  If the output is "less -R", I want --color, so I say
> "echo test | grep --color es", and I don't get color.  That's not what I
> asked for!