Re: Color-ls package

[Bill Hogan <bhogan@rahul.net>]

"SA" == Shawn Asmussen <shawn@nfinity.com> writes:

  SA> On Fri, 15 Mar 1996, Syrus Nemat-Nasser wrote:

  >> On Sat, 16 Mar 1996, Ian Jackson wrote:
  >> > I think that, given how badly designed colour-ls is, it should be done
  >> > in a separate package and should not replace the standard /bin/ls even
  >> > if you install it.  After all, given that dircolors is spouting stuff
  >> > to make aliases anyway it might as well include a path to the modified
  >> > ls.
  >>
  >> Fine. So I make a package which includes ls and dircolors in
  >> /usr/local/bin.  It also adds the dircolors manpage and places a
  >> (renamed) config file for dircolors in /usr/local/etc.  This is fine
  >> if people want to have extra binaries rather than alternate binaries.
  >>
  >> > You should certainly not release modified versions of other packages
  >> > and change only the version number; especially with fileutils (an
  >> > Essential package)
  >> 

    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.

    Bill

-- 
<bhogan@rahul.net>