Subject: Re: ncurses and terminfo are broken on Solaris/SunOS (Re: pkg/20881)
To: James K. Lowden <jklowden@schemamania.org>
From: Greg A. Woods <woods@weird.com>
List: tech-pkg
Date: 04/05/2003 14:34:48
[ On Saturday, April 5, 2003 at 00:18:43 (-0500), James K. Lowden wrote: ]
> Subject: Re: ncurses and terminfo are broken on Solaris/SunOS (Re: pkg/20881)
>
> Gregg's point AIUI is that xterm has to adhere to a standard if it's going
> to be useful outside the workstation.  If I fire up an xterm and use tip
> to dial a modem on some random non-NetBSD machine, that serial connection
> doesn't change xterm's cursor addressing characteristics.  I have to be
> able to define my terminal to that host if I want to use so much as vi,
> referencing an entry in the host's termcap.  There's no reason to assume
> the host has any knowledge of any nonstandard behavior my xterm might
> exhibit. [*] 

Yes, that's more or less it, at least w.r.t. the abstract issue of how
termcap and terminfo databases are associated with applications and not
terminals or terminal emulators.

> Starting with that assumption -- that xterm must rely on a standard larger
> than itself -- he asserts the termcap entry should be provided by the
> standard bearer.  And be part of the base OS, I think.  

Almost.  The termcap and terminfo entries need to be distributed with
the libcurses code that uses them since their format and content is
specific to the implementation of that code (witness the difference
between termcap and terminfo).  Ideally those entries should also be
written by someone familiar with both the libcurses code and the
terminal being described (e.g. have the manual, or the code if it's an
emulator, as well as an instance to test).

Unfortunately the real world isn't so perfect as the ideal world.  I
spent lots of time off and on during the first dozen years of my
experience managing Unix systems doing the job of tweaking termcap and
terminfo entries after discovering strange or undesirable behaviour from
applications on my (or my user's) terminal de jour and then pouring over
the manual for that terminal and the manuals for the termcap/terminfo
implementation used by those applications.  Unfortunately I often didn't
have access to the libcurses sources (nor the sources to applications
which mis-used libcurses), and sometimes I didn't even have good manuals
for the terminals either and had to just experiment and test until the
behaviour matched the user's expectations.

In more recent history there have been efforts to co-ordinate the
collection of accurate and tested terminal capability descriptions and
to collate them into "portable" termcap and terminfo distributions that
can be used with most libcurses implementations.  Unfortunately the
"users" of these distributions still end up introducing custom changes
for various reasons and as a result they end up with out-of-date
distributions and we're back where we started (witness NetBSD's very
out-of-date termcap).

What this still boils down to though is that implementations of terminal
emulators which are packaged in pkgsrc must not install their own
terminal capabilities description entries over top of, or in preference
to, entries that may come from somewhere else, but _should_ install
sample entries in some place that users can find them to use when
necessary.

The silly thing about the situation with pkgsrc screen and ncurses for
Solaris, where no native "screen" terminfo entry is available, is that
installing the "screen" entry into the nucrses-supplied terminfo
database doesn't do any good for any non-pkgsrc, non-ncurses,
applications used on that target host, regardless of which package
"owns" the entry file.

If any system or add-on provided termcap or terminfo (or whatever) entry
isn't correct for the current emulator implementation then that bug
needs to be fixed in the OS/package distibution and dealt with on an
individual basis by hacking and patching and such (just as it would have
to be done with a bug in an entry for a physical terminal).

> *   It would be cool though, if I could log in and say, "Hi this is me and
> this is my termcap entry.  Yeah, I know you've got one, but I'd really
> rather we use mine, thanks.  I don't know where yours has been, you know."

Sometimes that is possible.  See, for example, RFC 1408 and RFC 1572.

Unfortunately not all remote access protocols work the same way, and not
all remote access servers implement all the same features, and not all
potential target systems use $TERMCAP.  SSH-3.2.2 by default will only
transfer the value of $TERM and some termios settings to target
sessions, but not any other environment variables.  Getting the TERMCAP
value passed properly involves special configuration on the server to
allow the setting of $TERMCAP, and also requires a special option be set
for the client, which can be done on the command-line but cannot be done
dynamically in the ~/.ssh2/ssh2_config file (unless you regenerate that
file every time you change your $TERM).

Either way you're still no further ahead if one/more/all-of the
application(s) you use on the remote host don't use $TERMCAP....  :-)

($TERMINFO can only specify a filename, not an actual entry, though you
could first 'scp' the entry over to ~/.terminfo on the remote host :-)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>