[ksh93-integration-discuss] Small question about enabling the "multiline" mode...

[David Korn]

cc:  ksh93-integration-discuss at opensolaris.org
Subject: Re: Re: [ksh93-integration-discuss] Small question about enabling the "multiline" mode...
--------

> On 8/30/06, James Carlson <james.d.carlson at sun.com> wrote:
> > Roland Mainz writes:
> > > > The multiline option only works for terminals for which \E[A causes
> > > > the cursor to move up one line.  I suspect that this is not the case
> > > > for the terminal in your example.
> > >
> > > AFAIK all the terminal emulators shipped with Solaris (e.g. "dtterm",
> > > "xterm", "gnome-terminal" and "konsole"), the native Solaris console on
> > > SPARC and the Solaris/x86 console support that sequence (AFAIK it is
> >
> > Not if you switch to Tek mode.  ;-}
> >
> > > from vt100 or earlier (vt52 ?!)).
> >
> > No, not VT52.  That was pre-ANSI and used "ESC A" for the cursor-up
> > command.  The VT100 and up used ANSI sequences, which include "CSI A"
> > for cursor-up.  CSI can be rendered in 8-bit mode as hex 9B, or as
> > "ESC [" in 7-bit mode.
> 
> I assume ksh93 could only use the 7-bit mode - the 8-bit mode would be
> incompatible with multibyte output.
> A quick fix may be to enable the multiline option in /etc/ksh.kshrc
> only if if the terminfo command 'cuu1' is equal to  'CSI A':
> $ infocmp | fgrep "[A"
>         cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
> 
> > The terminal emulators in Solaris are roughly VT102 (including
> > scrolling commands that the VT100 didn't have).  But only roughly;
> > there are many differences among the various implementations and
> > between them and a real DEC VTxxx series terminal.  (Function key
> > assignment and usage is one quite large area of difference.)
> >
> > In any event, it'd sort of be nice to use the system libraries to get
> > the _right_ terminal sequences, just for those who are stuck using
> > oddball devices.
> 
> David, is a reason why ksh93 can't use the system libraries?
> 
> Irek
> 

The latest release uses infocmp internally to get the cursor up escape
sequence so it should work for any terminal in infocmp.

Since ksh might be installed as /bin/sh, I try to keep the startup
time down and the data area small since system() uses /bin/sh for
often very simple commands.  The time to fork() is affected by
the data size so adding libraries with large data areas can
slow down the time to fork().  This is why I don't link to libraries
unless necessary. 

David Korn
dgk at research.att.com