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

Re: Colour ls



(I won't get deeply enmeshed in the arguments about the merits of
colourfulness by default.  I think we should have the program, and
that if it does colourfulness by default it should only do it if
isatty(stdout) just as GNU ls currently columnises, and that it should
be possible to disable the colour on a per-user basis.  Colour by
default would make us more attractive to Slackware refugees.)

Dirk Eddelbuettel writes ("Re: Colour ls"):
> Problem with the Debian approach is that color-ls (the patch I compiled
> against GNU fileutils sometime last fall as well as the current patch that I
> grabbed it from <sunsite-linux-root>/utils/file/colors-ls-3.12.0.3.patch.gz a
> minute ago) is configured using an environment variable and some aliases.
> That seems to be in conflict with the 'all runs by default' policy that Ian J.
> advocates for and that I personally agree with. 

Can it not be compiled in such a way that it acts sensibly when the
environment variables and aliases are not set ?  Setting environment
variables to modify the default behaviour is entirely reasonable (I'm
less convinced about the need for aliases, but I'm unfamiliar with the
program).

James A. Robinson writes ("Re: Colour ls "):
> A postinst "Would you like color in your ls program?" or something
> would be nice.  I personally dislike it, but I remember reading
> several reviews of Slackware where they ohhed and ahhed over it. (like
> it was said, no accounting for taste (-: )

No, please, can we try to avoid prompting in postinsts ?  If we put it
back into fileutils (or whatever the package is) it should either be
there or not by default.  We need to keep prompting down to a minimum
(and we're being very successful so far, if I may say so).

Bill Mitchell writes ("Re: Colour ls"):
> That's the approach I'd advocate.  Fileutils being a debianized version
> of the fileutils package from upstream, and color-ls being a separate
> package with an alternative to fileutils-ls.
> 
> That gets us back to Richard Kettlewell's question when he offered to
> produce a color-ls package:  "doeS aNyBody know how should I arrange
> for this to interact sensibly with the fileutils package?"

See my recent message :-).

Bruce Perens writes ("Re: Colour ls "):
> I thought color "ls" was cool, though I think others didn't like it. I
> don't know why it was removed - was it a copyright issue?  I'd be
> willing to put it back in fileutils.

There couldn't be a copyright issue.  It's derived from GNU ls, so it
must be GPL'd or the author is in breach of the GPL.

Ian.


Reply to: