Date: Sun, 4 Jun 2000 19:23:41 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Doug Barton <DougB@gorean.org> Cc: Warner Losh <imp@village.org>, "Matthew N. Dodd" <winter@jurai.net>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Josef Karthauser <joe@pavilion.net> Subject: Re: cvs commit: src/bin/ls extern.h ls.1 ls.c ls.h print.c Message-ID: <Pine.NEB.3.96L.1000604191852.8938A-100000@fledge.watson.org> In-Reply-To: <393ADBA7.7A2B5BF9@gorean.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 4 Jun 2000, Doug Barton wrote:
> 3. First choice for 'ls -G' should be tgetstr(), with the ANSI codes
> left in as a fallback if that returns NULL. (Thus handling the case of
> no mounted /usr as well as possible.)
Forgive me my ignorance here -- the only situation I can imagine where
using hard-coded color codes would be appropriate would be where termcap
is not available, but a known-good terminal type is available via
getenv("TERM"). I don't believe there is any other appropriate situation
-- if color information is not available from termcap for the current
terminal, then no codes should be used as they are a priori inappropriate
as they're for a different terminal type :-).
So this leads me to the obvious question: if terminal information is not
available, why would we want to print out color codes? Is it not
acceptable to just not print in color when in single-user mode, or if the
termcap database is unavailable?
Robert
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000604191852.8938A-100000>