Re: ls color backwards compatibility

[Mikel Ward]

Thanks for the suggestion.

I've put my own customizations in ~/.dircolors.  If I run the command
dircolors ~/.dircolors in my ~/.shrc, I get pretty much what I want,
except for error messages like:
dircolors: `/home/mward/.dircolors':37: unrecognized keyword
STICKY_OTHER_WRITABLE
dircolors: `/home/mward/.dircolors':38: unrecognized keyword
OTHER_WRITABLE
dircolors: `/home/mward/.dircolors':39: unrecognized keyword STICKY

If I redirect stderr to /dev/null, it's fine.

The main problem is now /etc/profile.d/colorls.sh, which Red Hat puts on
its systems.  This one sources ~/.dircolors.$TERM (overriding my
settings), plus it doesn't discard stderr, so I get error messages every
time I log in on to an old box that doesn't support all the new
dircolors rules.

The other problem is how to have two groups: one for black on white
terminals ("light"), the other for white on black ("dark").  I want to
have
case $TERM in
konsole|rxvt|xterm*)
    eval $(dircolors ~/.dircolors.light)
    ;;
*)
    eval $(dircolors ~/.dircolors.dark)
    ;;
esac

but again the Red Hat stuff interferes.

Time to nuke /etc/profile.d/colorls.sh and file a bug against Red Hat.

Thanks

Mike