Re: Color-ls package
On Sat, 16 Mar 1996, Bill Hogan wrote:
> I believe that, just as every theory has primitive sentences
> (axioms) from which all other sentences in the theory must follow
> logically, every system has primitive components (functions) in terms
> of which all other components of the system are defined.
> Consequently, redefining a primitive system component raises havoc
> with every component in the system that was directly or indirectly
> defined in terms of it.
> In Unix, `ls' is a system component upon the definition of which
> countless other system components -- procedures, programs, and scripts
> of various kinds -- depend, and I think that is why the idea of
> replacing the standard Unix `ls' with something else continues to meet
> with negative enthusiasm.
> Better, I think, to let `ls' be `ls' and let your "colorized ls"
> be something entirely separate.
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.
While it is true that ls is a standard system component, it is
also true that there is more than one version of ls out there, and other
components in the system rely less on the need to have the 'one true ls'
than they do on ls following set standards of output. For the purposes of
interaction with other system components, there is to my knowledge no
distinction between the behavior of gnu ls and colorized gnu ls.