Re: Suggestion: try ~/.dircolors

[Jim Meyering]

Reuben Thomas <address@hidden> wrote:

> On Sat, 19 Jul 2008, Jim Meyering wrote:
>
>> Reuben Thomas <address@hidden> wrote:
>>> On Sat, 19 Jul 2008, Jim Meyering wrote:
>>>> Reuben Thomas <address@hidden> wrote:
>>>>> It would both be logical, and help with testing (where one wouldn't
>>>>> have to change one's login script) if dircolors tried to load
>>>>> ~/.dircolors if no database is given and the file exists.
>>>>
>>>> Or just put this in your start-up script:
>>>>
>>>>  d=.dircolors
>>>>  test -r $d && eval "$(dircolors $d)"
>>>
>>> That's fine, but, as always, good default behaviour is worth a hundred
>>> times as much as configuration: it doesn't need a user to work it out,
>>> read your mailing list message, or anything else. On the other hand,
>>> you could improve the differential by putting the above tip in the
>>> dircolors documentation.
>>
>> Would you like to prepare a patch that adds to doc/coreutils.texi
>> the sort of tip you would have liked to see?
>
> I'd rather the maintainers to have dircolors read a configuration
> file. So many programs do that, why not dircolors?

Sorry.  Not one other program in coreutils' set of 100+ does that,
and as far as I'm concerned, dircolors does not deserve an exception.

A few years ago, there was some discussion about whether dircolors
should honor /etc/DIR_COLORS.  Most of those arguments apply here.

In addition, if there's a vendor-supplied /etc/DIR_COLORS file on
your system, odds are good that it is out of date (lacking
some suffixes and/or newer attributes).