RE: Providing an alternative TERMINFO environment variable

[Igor Todorovski]

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).

 

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.

 

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>

> > | 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>

https://invisible-island.net