Bob Proulx wrote: > Lenny Domnitser wrote: >> It works fine, but it seems that it's a workaround for behavior ls >> could have. > > Since ls already has so very many features adding more features > requires a higher "activation energy" than adding features for other > commands. For something conceptually very simple the ls command has > become a very heavy application.
I would expect virtually every application that sends special terminal control sequences (such as those used for coloring) to respect the TERM variable and relevant terminal databases; it's just good manners. OTOH, making /bin/ls rely on ncurses is obviously be a bad thing. dircolors, OTOH, already /has/ its own terminal database built-in, which can be adjusted by passing it files. And, in fact, dircolors will give "LS_COLORS=''" if TERM=dumb, since it recognizes that it's not a color terminal (or more accurately, fails to recognize it as a color terminal in its database). It seems to me, then, that ls should never colorize in the case that LS_COLORS is /set/, but has a null value. Then the proper thing to do in a .bashrc is to simply ensure that dircolors' output is eval'd before invocation of a colorizing ls, and let dircolors/ls just DTRT. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
