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
