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

[Roland Mainz]

Glenn Fowler wrote:
> On Tue, 05 Sep 2006 09:48:53 +0200 Casper.Dik at Sun.COM wrote:
> > >What will happen if "infocmp" is not available at runtime, for example
> > >when "infocmp" lines in "/usr/bin/infocmp" but "/usr" isn't mounted yet
> > >and/or ksh93 lives in /sbin and the user only booted into a runlevel
> > >where /usr is not available ?
> > >The issue is quite tricky becase /usr/share/lib/terminfo/ lives in /usr
> > >which means there is no easy solution... ;-(
> 
> > Quite.
> 
> > Also, with Solaris you can use "lazyloading" which postpones the runtime
> > loading of libraries until such time functions in it are referenced.
> 
> another issue is, as much as possible, ksh attempts to provide similar
> behavior across all sw/hw architectures -- lazyload on m/n of them won't
> help the others
> 
> the short answer for /sbin vs /usr/bin is that
> /sbin only runtime is not full-featured;
> on systems where infocmp is in /usr/bin
> /sbin/ksh will not support termcap queries for cursor up for the same
> reasons infocmp is not in /sbin
> 
> the beauty from the ksh coding standpoint is that if cursor up
> for /sbin-only mode were a make-or-break feature for system X
> the solution would be for system X to add /sbin/infocmp (or at least a
> stub that handles $TERM's important to system X at /sbin-only time)
> and /sbin/ksh would work with no code/option change -- that /sbin/infocmp
> stub could even be limited to a specific set of TERM's and the cursor
> up capability

What about adding a shell variable which holds the output of
/usr/bin/infocmp ? In that case users could "save" the "infocmp" output
and store custom or "cached" values in their /etc/ksh.kshrc or ~/.kshrc
...
Example:
-- snip --
# set the "infocmp" information for terminal ${TERM}
.sh.terminfo.infocmp[$TERM]="$(/usr/bin/infocmp)"
-- snip --
The idea is that ".sh.terminfo.infocmp" is an associative array which
can hold multiple entries (one per "${TERM}" value) and therefore
provide a cache and avoids any problematic cases when ${TERM} gets
changed (otherwise a discipline function would be required to get the
"infocmp" information pulled again). If ".sh.terminfo.infocmp[$TERM]"
was not set yet it simply gets filled by calling "infocmp". An empty
string would mean: No information available.

There is one (minor ?!) nit: "infocmp" seems to contain information
about the terminals "cols", "lines" and other status information which
may be dynamic (for example the terminal window size) ... I am not sure
what is the best solution in this case ? Refresh the information on each
SIGWINCH or just ignore these fields in the cached "infocmp" output and
pull them via other methods on demand ?

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)