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. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
