Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Jan 2002 23:23:28 +0200
From:      Giorgos Keramidas <keramida@ceid.upatras.gr>
To:        Ted Mittelstaedt <tedm@toybox.placo.com>
Cc:        arch@freebsd.org, jasone@canonware.com
Subject:   Re: termcap versus terminfo
Message-ID:  <20020117212327.GA41262@hades.hell.gr>
In-Reply-To: <001501c19f3b$94c35280$1401a8c0@tedm.placo.com>
References:  <001501c19f3b$94c35280$1401a8c0@tedm.placo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2002-01-17 01:44:39, Ted Mittelstaedt wrote:
>
> The current FreeBSD scheme with the compiled termcap.db
> has terrible documentation.  In fact the only mention of the
> need to use cap_mkdb to build termcap.db is in the cap_mkdb
> man page, and it's not even a mention, it's just a link in
> SEE ALSO.  It's not mentioned in the man page for termcap.

This is a bug in the documentation.  It's not a termcap problem per
se, but the termcap manpage needs to be changed to include a section
about 'making local changes to the system termcap'.  If nobody has a
better suggestion, I'll try to come up with a small addition to
termcap's manpage in a few days.

> I don't see as how any admin is going to figure out how to add a terminal
> description other than trial and error so what "user friendliness" gained by
> holding to the human-readable /etc/termcap format is lost in the current
> scheme and really shouldn't be an issue to use in deciding between
> termcap and terminfo.
> 
> With regards to Terry's comments about corporate entities wanting
> to reduce support overhead, I think this is a bit pedantic.  Sun
> USED to keep infocmp separate in the Toolbox, but in Solaris 8,
> infocmp is included and can be used to extract terminfo source,
> and tic which is also included can be used to compile it back in.
> How many other commercial UNIX vendors are still unbundling infocmp
> I would ask - my guess is very few.  I don't see that the infocmp-edit-tic
> way of modifing the termcap entry is superior or inferior to the
> edit-termcap-and-run-cap_mkdb, from an admin's point of view.
> 
> The principle need admins have to tamper with terminfo or termcap entries is
> to work around deviations from whatever standard emulation their
> display devices are supposed to be following.  In the old days when
> terminal manufacturers would fix bugs and release new ROMS, the cost
> to an enterprise of running around and replacing them in their terminals
> pretty much guarenteed that once a terminal was installed, it would
> never be touched.  This meshed well with a central termcap authority
> controlling termcap entries in all UNIX everywhere because things
> didn't change much in the displays people were using, so it made
> sense to leverage effort to figure out the changes in new ROMS.
> 
> Today though, most people use terminal emulation on PC's or hardware
> devices with upgradable hardware, so there's much wider deviation from
> terminal emulation "standards" like the vt102, ANSI, Wyse60 and so on.
> And the deviations occur not just from emulation program to emulation
> program but from version to version.  So, having a single unified set of
> terminal entries that's kept maintained centrally isn't as important as it
> once was, because everyone has to change everything for their own stuff.
> What's more important is the default termcap supplied with the
> system have a set of common emulations, that people can use as starting
> points for their local mods.
> 
> 
> Ted Mittelstaedt
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-arch" in the body of the message

-- 
Giorgos Keramidas . . . . . . . . . keramida@{ceid.upatras.gr,freebsd.org}
FreeBSD Documentation Project . . . http://www.freebsd.org/docproj/
FreeBSD: The power to serve . . . . http://www.freebsd.org/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




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