Re: Not sure how to best reply re: dir_colors situation

[Jim Meyering]

Kamil Dudka wrote:

> On Sunday 07 of June 2009 17:30:28 Jim Meyering wrote:
>> Pádraig Brady wrote:
>> > Kamil Dudka wrote:
>> >> On Saturday 06 of June 2009 16:30:05 Pádraig Brady wrote:
>> >>> Kamil Dudka wrote:
>> >>>> I think we should improve documentation a bit. It is not only about
>> >>>> hard links. Some people may also want to disable file capabilities
>> >>>> highlighting, etc. Pádraig, what do you think?
>> >>>
>> >>> Well as discussed previously I'm not fond of this feature at all:
>> >>> http://lists.gnu.org/archive/html/bug-coreutils/2009-03/threads.html#00
>> >>>287 TBH, the number of hardlinks has it's own column that one can
>> >>> quickly scan. The only argument I've seen for changing the color is "it
>> >>> would help". So I'd be happy to turn off this completely, or at least
>> >>> not enable it by default.
>> >>
>> >> If this is what users want, then fine by me. Let's make the final
>> >> decision if "turn off completely", or "not enable by default". I'll
>> >> prepare the patch for review.
>> >
>> > Thanks Kamil for following this up.
>> >
>> > Turn off completely is my vote, as hardlinks have their own column.
>> > I polled my local LUG with a non leading question and
>> > nobody came up with a reason for coloring hardlinks.
>> >
>> > Eric voted for "not enable by default".
>> >
>> > Jim checked the functionality in originally.
>> >
>> > So I guess the middle ground is best of "not enable by default",
>> > though that will require adding documentation for the option.
>>
>> That sounds fine.
>>
>> > That's probably best to add in the dir_colors man page which
>> > is part of the linux man pages collection.
>> > Hmm, would this page be better located in coreutils?
>>
>> Much of that would be nice to add.
>> Other parts are not applicable.  i.e.,
>> neither /etc/DIR_COLORS nor ~/.dir_colors is honored.
>
> What do you think about the rename of HARDLINK to MULTIHARDLINK (as Joshua
> proposed)? And then maybe 'hl' to 'mh' accordingly? It makes sense, however
> it would break the configuration already done by users.

I prefer MULTIHARDLINK, too.

However, to do it right, we'd accept both HARDLINK and MULTIHARDLINK
for a while, first undocumenting HARDLINK, and later deprecating it
via a warning.  It may even be ok to warn about it already.
Then we'd remove support altogether in say, two years.
Possibly with intervening fail+diagnostic telling about the name change.
But maybe it's not worth all that.  It's new enough that I suspect very
few people have customized their set-up to use HARDLINK.

Same with "hl" vs. "mh".

That's a lot of work -- over a long period of time -- for small benefit.
If you're game, please mark the old strings as obsolete and with comments like

  FIXME-in-2011: warn about this obsolete string

so we remember to do it.