mabe02 / lanterna

Java library for creating text-based GUIs
GNU Lesser General Public License v3.0
2.26k stars 242 forks source link

need stty sane after Tutorial03 + 04 #575

Closed weberjn closed 1 year ago

weberjn commented 1 year ago

After running and exiting Tutorial03 + 04 the console does not echo input. Needs stty sane to have it work again. After 01+02 console is fine.

Debian 12. Java 17. kitty. ~/gitrepos/lanterna$ mvn exec:java -Dexec.classpathScope=test -Dexec.mainClass="com.googlecode.lanterna.tutorial.Tutorial04"

Same effect in xfce4-terminal. But here the sample is garbled, too:

image

avl42 commented 1 year ago

Your xfce4-terminal seems to be configured with a font that cannot display a certain set of characters...

To check this, type a command that reads stdin and ignores it, like "grep fvghsfdgsdfgs" and then paste the following chars and see if they show up.

┌─┐
│▼│
└─┘   

I couldn't reproduce the need for "stty sane" - after activating "Close" I came back to terminal and all fine.

PS: but then again, I'm currently on a somewhat dated branch of lanterna. Can you spot any late changes on the tutorials?

weberjn commented 1 year ago

ssh'ed in from MSYS2 mintty 3.6.4, the same effect as in kitty with Tutorial04.

And your grep test gives the correct output in my xfce4-terminal.

weberjn commented 1 year ago

Console is fine afterwards if you terminate Tutorial04 with System.exit(0); to trigger the VM shutdown hook.

mabe02 commented 1 year ago

I can't reproduce it either, will try a few more terminal emulators

weberjn commented 1 year ago

Sorry, I have mixed two different problems, the first one echo off after running (for which is a work-around with exit(0), but still should be fixed).

The second with the garbled output happens for me in XFCE4 Terminal and xterm, but only in FreeBSD, but curiously not if run from within tmux. I've run several times in the debugger to see if the Runtime exec stty calls have run into some problem, but they look fine.

weberjn commented 1 year ago

stty gives different output in tmux:

xterm, tmux in xterm

INFO: exec [/usr/bin/env, stty, -g] : gfmt1:cflag=4b00:iflag=2b02:lflag=5cf:oflag=3:discard=f:dsusp=19:eof=4:eol=ff:eol2=0:erase=8:erase2=8:intr=ff:kill=15:lnext=16:min=1:quit=1c:reprint=12:start=11:status=14:stop=13:susp=1a:time=0:werase=17:ispeed=38400:ospeed=38400 INFO: exec [/usr/bin/env, stty, -g] : gfmt1:cflag=4b00:iflag=2b02:lflag=5cb:oflag=3:discard=f:dsusp=19:eof=4:eol=ff:eol2=0:erase=7f:erase2=8:intr=ff:kill=15:lnext=16:min=1:quit=1c:reprint=12:start=11:status=14:stop=13:susp=1a:time=0:werase=17:ispeed=9600:ospeed=9600

avl42 commented 1 year ago

I don't have much experience with tmux - I use mainly "screen" instead - but some of the differences are "normal", like erase char being ^H or ^? and serial baudrates are usually just a legacy, anyway, unless you actually use a serial line...

Regarding exit(0) ... it's up to you to wrap the contents of your main(String[]) method in some try { ... } finally { exit(0); } to ensure sane exit in all but the worst (jvm-internal) crashes.

regarding xfce-terminal and garbled screen, it may be for some other legacy standard from times before utf-8. To send line-drawing characters, the terminal was switched with ^N to an alternate font mode, and then plain letters were treated as line-drawing and other characters. the ^O character usually set terminal back to letters-mode. Maybe, depending on locale and charset, lanterna might try that "alternative font"-approach, and xfce-terminal might not support it.

Edit: I tried the ^N/^O with 3 terminals, and neither of them accepted these chars. It's very likely, that these chars are no longer used these days... -- Looking at what the midnight commander "mc" does: it uses sequences \e(0 instead of ancient ^N and \e(B instead of ancient ^O - inbetween these escapes, e.g. a series of "qqqq..." turns into horizontal line chars.

For further diagnose of the xfce4-terminal behaviour, it would be good, if you could start script lanterna-dump as a command, and within the thus opened child-shell start the lanterna tutorial04, after exiting the application, also exit the shell and perhaps share a hexdump of the "lanterna-dump".

avl42 commented 1 year ago

Ok, my previous post was a bit longish... -- In a nutshell:

If I start tutorial04 in a UTF-8 xfce4-terminal, it works, and lanterna outputs the utf-8 chars for the line-drawing chars.

If I start tutorial04 in an ISO8859-1 xfce4-terminal (had to restart the terminal after changing the setting, to make it effective), then it uses \e(0q\e(B for each single horizontal line char. ... and it also works fine with xfce4-terminal.

Btw., my xfce4-terminal here claims to be version "0.8.7.4".

PS: In my application (that uses lanterna), I made a custom wrapper for the OutputStream, that would explicitly look for \e(B\e(0 sequences and eliminate them.

weberjn commented 1 year ago

Yes, I had not set LANG in xrdp startwm.sh With LANG=de_DE.UTF-8 it works, but not with an 8 bit set like LANG=de_DE.ISO-8859-15

weberjn commented 1 year ago

Looks like exit(0) is not enough, the CTRL-C behaviour is not restored.

avl42 commented 1 year ago

@weberjn so what version does your xfce4-terminal report? (in Help->About)

Also, xfce4-terminal has an extra setting (in Edit->Preferences-->Advanced->Encoding). Is that one setting synchronous with the LANG setting in your startwm.sh ?

Anyway, with all variants of LANG and xfce4-terminal setting that I tried, I cannot reproduce the garbled output. Maybe your xfce4-terminal is old? maybe it isn't even using the system installed one, but some old copy in ~/bin/ or any other PATH entry? Try type -all xfce4-terminal to see which one it is likely to pick up.

mabe02 commented 1 year ago

Same here : /

You said it only happens in FreeBSD though? Do you have any Linux-based system to try with?

weberjn commented 1 year ago

I can reproduce the garbled output on Debian Bookworm XFCE Terminal 1.0.4 and in xterm

with

unset LANG unset LANGUAGE unset LC_NAME unset LC_IDENTIFICATION

which gives

locale LANG= LANGUAGE= LC_CTYPE="POSIX" LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL=

mabe02 commented 1 year ago

Tried xterm (on Ubuntu) following your instructions above, still looks fine: image

Looking at your first screenshot, it seems like it's skipping over all the line drawing characters, probably UTF-8 encoded text is just ignored in your terminal. Or something with the font.

Now, a long long time ago, when I first wrote this library, it was supposed to run on Solaris servers that had no concept of UTF-8 and so I wrote conversion logic to try to avoid writing UTF-8 characters to terminal when the system platform wasn't UTF-8. Check out StreamBasedTerminal#translateCharacter and see which path it takes when you reproduce the issue. Maybe it thinks it's UTF-8 even though the terminal isn't?

weberjn commented 1 year ago

after UNSET LANG

jshell> System.getenv("LANG") $1 ==> null

Maybe it would be sufficient to just abort with an Exception("LANG is not set") ?

StreamBasedTerminal#translateCharacter

UTF8_REFERENCE UTF_8 (id=157) terminalCharset US_ASCII (id=64)

and it goes into the long switch block

avl42 commented 1 year ago

and it goes into the long switch block

That's just the right thing to do, imho. If it cannot detect UTF-8, go for the workaround. most terminals handle the "alternate charset" feature well, even those with utf-8 support.

A single terminal that misbehaves shouldn't spoil it for other "no LANG"-configurations.

On Mon, Jul 17, 2023 at 3:45 PM Jürgen Weber @.***> wrote:

after UNSET LANG

jshell> System.getenv("LANG") $1 ==> null

Maybe it would be sufficient to just abort with an Exception("LANG is not set") ?

StreamBasedTerminal#translateCharacter

UTF8_REFERENCE UTF_8 (id=157) terminalCharset US_ASCII (id=64)

and it goes into the long switch block

— Reply to this email directly, view it on GitHub https://github.com/mabe02/lanterna/issues/575#issuecomment-1638179000, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIDBMSJEGPKLNZUFIOE35LXQU6W3ANCNFSM6AAAAAAZ44BVGE . You are receiving this because you commented.Message ID: @.***>

mabe02 commented 1 year ago

Sorry, not sure I follow. What code change are you proposing?

weberjn commented 1 year ago

Let's put to rest the garbled screen topic, it can be fixed with LANG.

But it would be nice if Tuturial03+04 could be fixed that they don't leave the screen in need for stty sane.

mabe02 commented 1 year ago

Trying to figure out what we need to do; the tutorial is calling stopScreen() at the end which should already reset the terminal. Here's what I get when I check stty before and after:

$ stty -a
speed 38400 baud; rows 40; columns 158; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc
$ java -cp target/classes:target/test-classes com.googlecode.lanterna.tutorial.Tutorial04
$ stty -a
speed 38400 baud; rows 40; columns 158; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc
$

Looks identical to me

weberjn commented 1 year ago
[INFO] Scanning for projects...
[INFO] Inspecting build with total of 1 modules...
[INFO] Installing Nexus Staging features:
[INFO]   ... total of 1 executions of maven-deploy-plugin replaced with nexus-staging-maven-plugin
[INFO]
[INFO] ------------------< com.googlecode.lanterna:lanterna >------------------
[INFO] Building Lanterna 3.2.0-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- exec:3.1.0:java (default-cli) @ lanterna ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  8.277 s
[INFO] Finished at: 2023-07-22T16:26:44+02:00
[INFO] ------------------------------------------------------------------------
weberjn@berlin:~/gitrepos/lanterna$
weberjn@berlin:~/gitrepos/lanterna$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"

second to last command line was blindly typed stty sane

Terminal is kitty.

mabe02 commented 1 year ago

Ok, I'll try the same

mabe02 commented 1 year ago

Ok, can reproduce now, if I run mvn from bash. I normally use fish and from there it works.

mabe02 commented 1 year ago

I've pushed what I think will fix this

weberjn commented 1 year ago

Problem fixed now. Thank you.