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

[Jim Meyering]

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.

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.