Re: The JLine impact of the hex change in infocmp

[Thomas Dickey]

On Sat, Jun 03, 2017 at 08:30:27AM +0200, eugene yokota wrote:
> Hi,
> 
> I'm a maintainer of sbt, an interactive build tool used for Scala
> programming language. Recently there was a bug report from Arch Linux users
> that updating to ncurses 6.0+20170527-1 throws an exception at startup [1].
> It turned out that this is due to [jline2#281], which did not handle the
> hexadecimal output in infocmp.
> 
> Given that infocmp itself is called indirectly there's not much the users
> can do to hold off the upgrade of ncurses. I see this is an ominous sign
> since in some time horizon, the change will be propagated to more wider
> usage beyond Arch Linux or Mac Port users who might be willing to downgrade.
> Also note that Scala comes with a REPL interpreter, which also uses a fork
> of JLine.
> 
> Are there potential workaround for this? Fixing JLine and updating to a new

I considered whether it was necessary to add an option to infocmp,
but seeing that X/Open Curses has documented it for more than twenty
years (and that ncurses's tic has accepted hex/octal/decimal constants
for about as long), didn't see a need.

It's shown here:

http://pubs.opengroup.org/onlinepubs/7908799/xcurses/terminfo.html#tag_002_001_002

        A positive integer which conforms to the C language convention for
        integer constants. 

(and verified by testing with Solaris).

> version alone I don't think is a good solution since that would mean that
> all older versions of sbt or Scala REPL would no longer work.

The straightforward approach is to fix the problem, recommend an upgrade
and provide a patch for people who really want to run the older version...

(for what it's worth, the NetBSD developers had to fix some latent bugs
in their tools as well).

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

signature.asc
Description: Digital signature