[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suggestion: try ~/.dircolors
From: |
Jim Meyering |
Subject: |
Re: Suggestion: try ~/.dircolors |
Date: |
Sat, 19 Jul 2008 20:42:08 +0200 |
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).