Re: Color-ls package
Shawn Asmussen:
> I couldn't disagree more. Color ls is designed specifically to
> replace ls. If you're not going to use it in this manner, I don't
> think you should use it at all. Color ls is the standard ls with
> patches to allow colorized output. If color output is not specified
> implicitly, color ls behaves precicely as does ls, and I have never
> seen a problem with it's interaction with any other utility. The
> standard method of using color is for --color=tty to be used, where
> color is only outputed if the output is going to a true tty, and if
> the output is instead piped to another command, or routed to a file
> it omits the color codes, preventing them from confusing any
> programs that the output may be sent to.
I think this has been pretty well thrashed out, but I just want to
remind you of a couple issues:
(1) programs that run ls under a pty (e.g. wish scripts using expect)
can easily be confused by these sorts enhancements that change
behavior.
(2) emacs has had all sorts of problems with subprocesses, in my
experience. [e.g. things would work fine for several days, then all
of a sudden I'd start getting nulls from subprocesses.] It's probably
not a good idea to change the playing field until we're certain that
this issue is gone. [And, yes, emacs does use ls.]
(3) We're still sorting out termcap/terminfo/curses/ncurses/slang/...
It's probably wise to anticipate some rough edges [especially for
processes not running on the linux console].
Summary: I don't think now is the time to integrate this variant ls
with fileutils. And, I think it would be much more pleasant if it can
be ignored, should the user find it a problem.
--
Raul
Reply to: