coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: Re: Bug#582083: patch for grep --color to non-tty output
Date: Tue, 24 Apr 2012 10:36:09 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

[adding coreutils]

On 04/24/2012 09:43 AM, Jim Meyering wrote:

>>> 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.

And probably harder to track down and ultimately fix, but not impossible.

>>> 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.

Personally, I think ls has it wrong - I _like_ --color defaulting to
--color=auto, and think ls has it wrong.  Thankfully, you can always use
--color=mode to say what you mean, so if you are aware of the
inconsistent defaults of --color in isolation, you just avoid that
construct.

In other words, this is all boiling down to a bikeshed painting contest.
 I _do_ value consistency, and I would welcome a change that first
documents our intention to make a change to a default (whether that
change is to grep, to ls, to the GNU Coding Standards, or somewhere else
is still up for debate....), and only after another year or two go ahead
with the change.  But I'm not happy with forcing a change in bikeshed
behavior with no warning.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]