Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 May 1997 18:47:03 +0200 (MET DST)
From:      Eivind Eklund <perhaps@yes.no>
To:        Terry Lambert <terry@lambert.org>
Cc:        perhaps@yes.no, pgiffuni@fps.biblos.unal.edu.co, imp@village.org, karpen@ocean.campus.luth.se, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG
Subject:   Re: 2.2 Splashkit
Message-ID:  <199705151647.SAA27756@bitbox.follo.net>
In-Reply-To: Terry Lambert's message of Wed, 14 May 1997 10:18:27 -0700 (MST)
References:  <199705140653.IAA23749@bitbox.follo.net> <199705141718.KAA12821@phaeton.artisoft.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> > colorls has a whole bunch of problems.  However, linuxls with colors
> > actually work quite nicely - it defaults to no colors (yeah!), and has
> > a '--color=tty' option that will only do color sequences if you
> > actually use a tty, making it work without problems in a pipe.
> 
> You know, I tried this.  It gave me a whole lot of additional
> information in color of the type normally provided "in band" by
> "ls -F", and it statted all the files to do it (which a normal
> "ls" does not).

If we should ever end up having this standard, we'll have to do it as
a patch to our own ls, not just picking up the one from Linux - no
extra GNU licenses, please.

> Then I went to my Televideo 925, and all the information was lost.
> Good thing I didn't use it long enough to become dependent on it.

I've used it for quite some time, but I'm not dependent on it - it
just makes me work a little bit quicker, because the cues are more
obvious without being more obstructive.

> The problem with color utilities is that if the color is important
> to their function, then their function is easily damaged by a lot
> of hardware out there.

True.  However, that is always the problem with extending
functionality - you can't go back.

Eivind.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705151647.SAA27756>