[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

(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.


Reply to: