Re: Providing an alternative TERMINFO environment variable

[Thomas Dickey]

On Sun, Dec 03, 2023 at 01:44:59AM +0000, Igor Todorovski wrote:
> Hi,
> 
> I’m not sure if the Java situation is the same as what I’m experiencing.
> 
> On z/OS, you can build an application in either EBCDIC (legacy) or ASCII
> mode.
> 
> There are some EBCDIC applications built with curses and which rely on the
> TERMINFO database shipped with z/OS.
> 
> I’m building ASCII applications with ncurses, but If we set the TERMINFO
> environment variable it will break the EBCDIC applications (they also read
> TERMINFO) shipped with the OS as they cannot interpret the terminfo database
> from ncurses (built in ascii).

yes - you'd like a way for both ASCII and EBCDIC applications to ignore the
other's terminal database.  Adding $NCURSES_TERMINFO would solve one part of
the problem, and possibly modifying ncurses's terminfo reader would solve the
problem where someone forgets to set $NCURSES_TERMINFO
 
> I can probably package z/OS terminfo database if that helps.  We also can
> provide access to one of our public z/OS machines.  Let me know.

I'm uncertain about a package (because package formats differ widely),
but a POSIX tar file of the EBCDIC terminfo directory tree along with
the zOS curses's "term.h" file would give me plenty of information to
analyze.
 
> Thanks,
> Igor
> 
> On 2023-12-02, 9:55 AM, "bug-ncurses-bounces+itodorov=ca.ibm.com@gnu.org" 
> <bug-ncurses-bounces+itodorov=ca.ibm.com@gnu.org> wrote:
> On Fri, Dec 01, 2023 at 05:37:53PM -0600, G. Branden Robinson wrote:
> > At 2023-11-29T14:50:39-0500, Thomas Dickey wrote:
> > > ----- Original Message -----
> > > | From: "G. Branden Robinson" 
> > > <g.branden.robinson@gmail.com<mailto:g.branden.robinson@gmail.com>>
> > > | At 2023-11-28T17:14:26+0000, Igor Todorovski wrote:
> > > |> I have added the below code to enable setting ASCII_TERMINFO. I’m
> > > not |> sure if the environment variable name is reasonable or not, but
> > > the |> z/OS system default checks for TERMINFO so I needed a way to
> > > tell |> ncurses where to pick up tis terminfo db.
> > > |>
> > > |> Is there a better alternative?
> > > |
> > > | Doesn't TERMINFO_DIRS do this job?
> > >
> > > No - $TERMINFO is tested first, and if he has some other
> > > implementation where he is setting $TERMINFO, there's a conflict.
> >
> > I see now.  Why not make Igor's proposed environment variable
> > "TERMINFOPATH", since it would then have semantics like other *PATH
> > variables (being an override), and _not_ make it conditional on a z/OS
> > symbol, but applicable everywhere?
> 
> But it's not a general problem.  If I provide it "everywhere", it's
> certain that others using ncurses terminfo will provide conflicting
> implementations, resulting in a nuisance.
> 
> See the earlier discussion here -
> 
> https://lists.gnu.org/archive/html/bug-ncurses/2023-02/msg00008.html
> 
> ncurses checks that the compiled terminfo follows some formatting rules,
> but assumes that the strings stored in the terminfo database do not need
> translation.  Apparently zOS is storing strings in EBCDIC and later
> (in tput?) converting to ASCII.
> 
> If I had more information on what the zOS terminal database contents
> were, I'd prefer to do a sanity check on it to ensure that it's not
> returning data that was translated to EBCDIC.
> 
> https://www.ibm.com/docs/en/iis/11.7?topic=tables-ascii-ebcdic
> 
> For instance, checking the cursor_address capability, which often
> begins \E[, I'd expect something like this:
> 
>                                 ASCII      EBCDIC
>                 \E            0x1b      0x27      "'"
>                 [              0x5b      0x4a       "J"
> 
> There are other two-character prefixes, but that's an example of something
> that I could do to ignore the unwanted data -- on zOS.
> 
> --
> Thomas E. Dickey 
> <dickey@invisible-island.net<mailto:dickey@invisible-island.net>>
> https://invisible-island.net
> 

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

signature.asc
Description: PGP signature