[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 ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature