`NumberFormatException` when parsing terminal capabilities

[alaz]

Hello,

I am running the following command and get the output:

$ JAVA_OPTS='-Djline.internal.Log.debug=true' sbt
[DEBUG] Creating terminal; type=auto
[DEBUG] Config: speed 9600 baud; 34 rows; 100 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
    -echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
    -extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel iutf8
    -ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
    -dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
    eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
    min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
    stop = ^S; susp = ^Z; time = 0; werase = ^W;

[ERROR] Failed to construct terminal; falling back to unsupported
java.lang.NumberFormatException: For input string: "0x100"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Integer.parseInt(Integer.java:580)
    at java.lang.Integer.valueOf(Integer.java:766)
    at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
    at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:242)
    at jline.UnixTerminal.<init>(UnixTerminal.java:65)
    at jline.UnixTerminal.<init>(UnixTerminal.java:50)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at java.lang.Class.newInstance(Class.java:442)
    at jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
    at jline.TerminalFactory.create(TerminalFactory.java:102)
    at jline.TerminalFactory.get(TerminalFactory.java:186)
    at jline.TerminalFactory.get(TerminalFactory.java:192)
    at sbt.ConsoleLogger$.ansiSupported(ConsoleLogger.scala:123)
    at sbt.ConsoleLogger$.<init>(ConsoleLogger.scala:117)
    at sbt.ConsoleLogger$.<clinit>(ConsoleLogger.scala)
...

infocmp shows:

infocmp 
#   Reconstructed via infocmp from file: /opt/local/share/terminfo/78/xterm-256color
xterm-256color|xterm with 256 colors,
    am, bce, ccc, km, mc5i, mir, msgr, npc, xenl,
    colors#0x100, cols#80, it#8, lines#24, pairs#0x7fff,
    acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
    bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
    clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=\r,
    csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
    cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C,
    cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
    cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
    dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
    el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, home=\E[H,
    hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
    il=\E[%p1%dL, il1=\E[L, ind=\n, indn=\E[%p1%dS,
    initc=\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
    invis=\E[8m, is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~,
    kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D,
    kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=^H,
    kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
    kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~,
    kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q,
    kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~,
    kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~,
    kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~,
    kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S,
    kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~,
    kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~,
    kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q,
    kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~,
    kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~,
    kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~,
    kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q,
    kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
    kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
    kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
    kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
    kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~,
    kind=\E[1;2B, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
    kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El,
    memu=\Em, oc=\E]104\007, op=\E[39;49m, rc=\E8, rev=\E[7m,
    ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B,
    rmam=\E[?7l, rmcup=\E[?1049l, rmir=\E[4l, rmkx=\E[?1l\E>,
    rmm=\E[?1034l, rmso=\E[27m, rmul=\E[24m,
    rs1=\Ec\E]104\007, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7,
    setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
    setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
    sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
    sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
    smcup=\E[?1049h, smir=\E[4h, smkx=\E[?1h\E=,
    smm=\E[?1034h, smso=\E[7m, smul=\E[4m, tbc=\E[3g,
    u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?%[;0123456789]c,
    u9=\E[c, vpa=\E[%i%p1%dd,

[gnodet]

Out of curiosity, what's your OS ?

[alaz]

OS X "El Capitan", 10.11.6. In fact everything was just fine until recently and I don't know what exactly changed.

[alaz]

Aha, it's MacPorts' ncurses update that was guilty:

$ sudo port provides /opt/local/share/terminfo/78/xterm-256color
/opt/local/share/terminfo/78/xterm-256color is provided by: ncurses

$ sudo port installed ncurses
The following ports are currently installed:
  ncurses @6.0_0
  ncurses @6.0-20170422_0
  ncurses @6.0-20170520_0 (active)

$ sudo port activate ncurses @6.0-20170422_0
--->  Deactivating ncurses @6.0-20170520_0
--->  Cleaning ncurses
--->  Activating ncurses @6.0-20170422_0
--->  Cleaning ncurses

$ infocmp 
#   Reconstructed via infocmp from file: /opt/local/share/terminfo/78/xterm-256color
xterm-256color|xterm with 256 colors,
    am, bce, ccc, km, mc5i, mir, msgr, npc, xenl,
    colors#256, cols#80, it#8, lines#24, pairs#32767,
    acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
    bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
…

[eed3si9n]

This change to ncurses effectively renders old versions of jline and sbt useless once it becomes more widely used. I think we should raise the issue back to the maintainers and lobby against it, or at least let them know of the impact.

[gnodet]

Fwiw, I've just released JLine 2.14.4 to fix this issue.

[splatch]

FYI ran into same issue with arch linux (and fish shell):

#   Reconstructed via infocmp from file: /usr/share/terminfo/x/xterm-256color
xterm-256color|xterm with 256 colors,
    am, bce, ccc, km, mc5i, mir, msgr, npc, xenl,
    colors#0x100, cols#80, it#8, lines#24, pairs#0x7fff
...

An workaround for this issue before bugfix is setting TERM environment variable to xterm-color.

[cecton]

Same for me on Arch Linux with screen in 256 colors:

#       Reconstructed via infocmp from file: /usr/share/terminfo/s/screen-256color
screen-256color|GNU Screen with 256 colors,
        am, km, mir, msgr, xenl,
        colors#0x100, cols#80, it#8, lines#24, pairs#0x7fff,

I switched the TERM to screen instead of screen-256color

[gnodet]

Yes, the output has been changed from colors#256 to colors#0x100 ... The jline code needs to be adapted. If someone could provide a patch...

Guillaume Nodet

Le mer. 16 août 2017 à 09:06, Cecile Tonglet notifications@github.com a écrit :

Same for me on Arch Linux with screen in 256 colors:

Reconstructed via infocmp from file: /usr/share/terminfo/s/screen-256color

screen-256color|GNU Screen with 256 colors, am, km, mir, msgr, xenl, colors#0x100, cols#80, it#8, lines#24, pairs#0x7fff,

I switched the TERM to screen instead of screen-256color

— You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub https://github.com/jline/jline2/issues/281#issuecomment-322697089, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFINjm5d0sus77HgS9SCM57c-2pqoW5ks5sYqLtgaJpZM4NqILD .

--

Guillaume Nodet

Red Hat, Open Source Integration

Email: gnodet@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/

[cecton]

Hmmm.... I would gladly change it if the code change is quite obvious but I have never done anything in Java...

[gnodet]

I'm in vacation. This problem has actually already been fixed and released in jline 2.14.4.

[danberindei]

The terminfo spec says integer values can have any format allowed for C literals, perhaps it would be a good idea to allow octal (and maybe binary) encoding as well?

https://lists.gnu.org/archive/html/bug-ncurses/2017-06/msg00001.html