Lenny Domnitser wrote: > On 6/13/07, Bob Proulx <[EMAIL PROTECTED]> wrote: >> Improving this seems like a reasonable enhancement. > > If you think changing the behavior of --color=auto will break things, > I can do --color=smart, i.e. the TERMinal is not dumb.
Given that "dumb" isn't the only terminal type that doesn't support color, and that dircolors ostensibly knows (non-comprehensively) which ones do, I'd still vote for letting dircolors do the term detection (that it already does), and have ls handle a set-but-empty LS_COLORS accordingly. For my part, I'm having a hard time envisioning any problems that could be caused by using --color=auto for this; at least, exporting an empty LS_COLORS when one means for ls to rely on its default color settings seems an unnatural idiom: leaving LS_COLORS unset (for instance, by neglecting to evaluate dircolors' output) seems a much more natural idiom, and I would hope that's how people who want the defaults are already doing it. Additionally, if there are some people who are using the method that will become broken, it will be easy to fix, and will not cause any loss in functionality or breakage elsewhere, since it is inconceivable that scripts parsing ls's output would be relying upon ls to output some particular color sequences (or, even any color sequences). -- 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
