Subject: Re: ncurses and terminfo are broken on Solaris/SunOS (Re: pkg/20881)
To: Michael Schroeder <Michael.Schroeder@informatik.uni-erlangen.de>
From: Greg A. Woods <woods@weird.com>
List: tech-pkg
Date: 04/03/2003 14:41:31
[ On Thursday, April 3, 2003 at 11:49:37 (+0200), Michael Schroeder wrote: ]
> Subject: Re: ncurses and terminfo are broken on Solaris/SunOS (Re: pkg/20881)
>
> > Either way screen's maintainers are only making the situation much worse
> > by providing a differently named terminfo/termcap entry for use on
> > target hosts. If they simply called their entry "ansi" and only
> > suggested it be installed when the target system didn't have a (working)
> > "ansi" entry then I couldn't and wouldn't complain.
>
> Oh, is that so? And why do you think there is an "xterm" terminfo
> entry?
Well, I don't really think there _should_ be an "xterm" terminfo either,
but there is one mostly because many xterm programs provide a rather
non-standard terminal emulation, especially when it comes to keyboards,
but even for really standard stuff like SGR and colours, etc.
Of course from an application's (libcurses) point of view there's no one
standard "xterm" emulation implementation either. Unfortunately out in
the real world there are many and varied xterm implementations in daily
use, and they have many, sometimes subtle but usually important,
differences which require unique termcap or terminfo descriptions. If
Xterm had only ever tried to be a purely standards based terminal
instead of trying to emultate one or more real-world hardware terminals
then maybe we wouldn't be stuck with many and varied "xterm" terminfo
and termcap entries all over the place too.
I think in an ideal world "screen" would not do any terminal emulation
and would simply maintain as transparent a pipe through to each session
as is possible, though of course that means giving up on some of the
"bloated" features people have come to expect from "screen". Any
emulation layer anyone might need to access an application that doesn't
have flexible enough terminal drivers (e.g. there is no underlying
libcurses on the target host and the user is using a terminal that the
application can't drive) should be optional and should be implemented in
a separate program from whatever is used to provide session
multiplexing.
In the real world all virtual windowing and terminal software, including
"screen" as it is implemented today, should strive to implement only
standards based terminal emulation and should only offer tools like
termcap and terminfo entries for those users who are using target
environments where the native tools for describing standard terminals
are broken. Remember not every user can easily have special terminal
description database entries added to the target systems they might
access through such virtual windowing software. ECMA-48 is no joy to
read, but it is freely available, and if you stick just to it then for
the most part "screen" can present itself to target sessions as a purely
standard "ansi" terminal and there'll never be any need for a unique
"screen" terminal type.
--
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>