Reuben Thomas <[EMAIL PROTECTED]> wrote: > On Sat, 19 Jul 2008, Jim Meyering wrote: > >> Reuben Thomas <[EMAIL PROTECTED]> wrote: >>> On Sat, 19 Jul 2008, Jim Meyering wrote: >>>> Reuben Thomas <[EMAIL PROTECTED]> 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). _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
