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>