need stty sane after Tutorial03 + 04
weberjn opened this issue · 24 comments
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:
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?
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.
Console is fine afterwards if you terminate Tutorial04 with System.exit(0); to trigger the VM shutdown hook.
I can't reproduce it either, will try a few more terminal emulators
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.
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
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".
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.
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
Looks like exit(0) is not enough, the CTRL-C behaviour is not restored.
@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.
Same here : /
You said it only happens in FreeBSD though? Do you have any Linux-based system to try with?
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=
Tried xterm (on Ubuntu) following your instructions above, still looks fine:
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?
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
Sorry, not sure I follow. What code change are you proposing?
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.
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
[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.
Ok, I'll try the same
Ok, can reproduce now, if I run mvn from bash. I normally use fish and from there it works.
I've pushed what I think will fix this
Problem fixed now.
Thank you.