Subject: Re: ncurses and terminfo are broken on Solaris/SunOS (Re: pkg/20881)
To: None <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 04/03/2003 16:43:03
[ On Thursday, April 3, 2003 at 14:23:43 (+0200), Juergen Weigert wrote: ]
> Subject: Re: ncurses and terminfo are broken on Solaris/SunOS (Re: pkg/20881)
> On Apr 02, 03 12:12:22 -0500, Greg A. Woods wrote:
> > [ On Wednesday, April 2, 2003 at 08:04:18 (+0200), Matthias Scheler wrote: ]
> > > Subject: Re: ncurses on broken on Solaris (Re: pkg/20881)
> > > On Wed, Apr 02, 2003 at 12:01:46AM +0200, Klaus Heinz wrote:
> > > >
> > > > No. Further digging in the CVS log reveals, that Matthias Scheler
> > > > committed this workaround last year. Maybe he can remember why he did it
> > > > this way.
> > >
> > > Because it conflicted with the "screen" package.
> > The "screen" package must not install any terminfo or termcap entries on
> > the host where the package is installed!
> Sorry, I missed the start of this thread, but what I read here makes me
> frown. Looks like a problem of understanding.
Note that I'm speaking there very specifically about which package
"owns" the files for the terminal descriptions....
Since the ncurses package already provides a perfectly good
terminfo-style "screen" terminal description there is no need for the
screen package to replace them, nor for any other package to do so
If, and only if, the base system provides its own terminfo database, and
if and only if there are to be "screen" terminal type descriptions added
to that system provided database by some add-on package then they should
be added by a separate stand-alone package, not the "screen" package.
This way the screen package can be consistent in its offering across
pkgsrc-supported platforms, and ncurses can provide its own "private"
terminfo descriptions for the "screen" terminal type.
Note the base NetBSD distribution doesn't come with a "screen"
description in its termcap database. Unfortunately though there's not
currently any decent way for an add-on package to "enhance" the base
termcap database -- one of the flaws of the "termcap" scheme, at least
as it's normally implemented.
> Every terminal type that the system provides to client applications,
> should be described by a terminfo or termcap entry.
You've got that backwards in a way, or inside out, or something. :-)
Every terminal type that the system provides for _users_ is described by
a terminfo or termcap entry. Applications (and usually just libcurses)
read those descriptions and make use of them to, hopefully, direct the
user's terminal to do the right thing (and to figure out what function
key the user has pressed, etc.).
In a libcurses-only environment (i.e. where all applications use a
libcurses-like library to provide terminal independence) it is only
termcap and terminfo entries which "provide" terminal types for use by
users, not applications and not even libcurses itself.
Applications (at least ones using a libcurses) can't support a terminal
type without there being a termcap or terminfo entry for that terminal.
There's no "should" about it.... :-)
> As screen is neiter a transparent multiplexer nor does implement and
> restrict itself to any already well known standard, we have to have a
> machine readable way to document what it is. It is very close
> to ECMA-48 though.
This is somewhat off the topic of packaging screen, but since I seeded
the thought in the first place....
Are not the existing "ansi" terminfo and termcap descriptions provided
by most systems sufficiently compatible with screen to be used as-is?
If not, why not? If not can the differences be accomodated in the
"ansi" terminfo and termcap descriptions without adversely affecting
the ability of those entries to drive true standards-compatible
terminals or emulators?
Why doesn't "screen" restrict itself to strict ECMA-48 compatability?
(Of course window(1) in NetBSD is even worse -- it creates out its own
tailored TERMCAP environment variable setting for each virtual window
session and there's no standard way to "enable" that setting for use on
an arbitrary client system should that session be used to access some
other client system.)
> No. Ncurses reads termcap entries.
(actually ncurses uses terminfo, but that's more or less irrelevant here...)
> If it would bring its own set, one could
> never know that they really match the terminal tyes that are implemented in
> the system.
Ncurses does in fact come with its own complete terminfo database,
including an entry for a terminal emulator called "screen" (and a
perfectly usable entry at that).
If the ncurses-provided terminfo definitions don't work with the
terminals they're supposed to work with then that's a bug in the ncurses
distribution (which could be fixed in the interim with a patch in pkgsrc
Users who know their system-(or add-on-package)-provided terminal
descriptions are broken for their terminals can, if they are savvy
enough with environment variables and such, use corrected entries.
Greg A. Woods
+1 416 218-0098; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>