Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Jan 2002 01:44:39 -0800
From:      "Ted Mittelstaedt" <tedm@toybox.placo.com>
To:        <arch@freebsd.org>
Cc:        <jasone@canonware.com>
Subject:   Re: termcap versus terminfo
Message-ID:  <001501c19f3b$94c35280$1401a8c0@tedm.placo.com>

next in thread | raw e-mail | index | archive | help

For starters I'm not particularly a terminfo supporter, my main
concern is seeing something that's easy to use and works.  But
I feel the current FreeBSD scheme doesen't work - at least not
from an administration standpoint.

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.

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001501c19f3b$94c35280$1401a8c0>