[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).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]