So here's the stty -g before and after:

"gfmt1:cflag=4b00:iflag=6b02:lflag=200005cb:oflag=3:discard=f:dsusp=19:eof=4:eol=ff:eol2=ff:erase=7f:intr=3: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"
"gfmt1:cflag=4b00:iflag=6802:lflag=4cb:oflag=3:discard=f:dsusp=19:eof=4:eol=ff:eol2=ff:erase=7f:intr=3: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"

Unless my eyes deceive me, lflag goes from 200005cb to 4cb.

Using -a output, here's before and after for lflag:

lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
lflags: -icanon isig iexten echo echoe -echok echoke -echonl echoctl

So icanon is not being restored.

icanon sets "canonical mode" according to the manpage:

Enable (disable) canonical input (ERASE and KILL processing).

I'm not sure what the equivalent is in jline (the library we use for readline) but I will investigate.

Well, that didn't take long.

I found this little nugget in the UnixTerminal class from jline:

    public void init() throws Exception {
        super.init();
        this.setAnsiSupported(true);
        this.settings.set("-icanon min 1 -icrnl -inlcr -ixon");
        this.setEchoEnabled(false);
    }

So it looks like it disables canonical input when we start using it and never turns it back on. This is a bug in jline...I suggest you file it there (https://github.com/jline/jline2), reference this bug, and I will help you work with them to come up with a fix.

We'll leave this open meanwhile.

FWIW your workaround of restoring with stty is probably good enough for now; it appears that jline just uses stty for terminal modes anyway.

Hi @headius

With the fragment of code you have posted I was able to walk a little at the code and see that "indeed" for "unix" terminals they just use stty external program (as I was doing). So I will stay with this workaround. Thank you very much!

I have opened the issue on JLine as you told me.

I don't know what your policies for issues like this, that are pending because of external issues. Do you just close the issue? Or you let it open until the external dependency gets fixed? I'm good with both, so feel free.

We would leave it open. Unfortunately, it doesn't appear that jline2 is very active right now :-\

Hi @headius,

Just commenting here to let you know that we have merged the PR JEG2/highline#149

We have opted to call Readline.readline inside a block that saves and restores the stty state afterwards.
See commit: abinoam/highline@a9d3604
We still have some issues with that.

I think you have commented on using rb-readline in place of the builtin readline (I'm not sure).
We have also tried it. But we're having issues with multibyte characters.
See this gist https://gist.github.com/abinoam/c8e81f7c0e851bee40f4

I'll try to open an issue on rb-readline for that.

Rawline, as the other option, is looking a little unmaintained, as far as I could see.

So, we still don't have the silver bullet to make things work at different platforms.

I have reported 2 issues on rb-readline

ConnorAtherton/rb-readline#123

ConnorAtherton/rb-readline#124

See jline/jline2#210 (comment).
I came across similar behavior in Scala world, and found this thread and jline/jline2#210 helpful.

here should be some progress here (for JRuby >= 9.2.4.0) with jruby-readline 1.3.7 restoring should be in place
however, e.g. during irb, stty still reports changed settings ... jruby-readline 1.4.0 will likely restore after each readline op

Move another Readline issue into 9.3.0.0, since we intend to ship the reline library which will replace our jline-based impl.

Interestingly this still seems to be a problem with reline instead of readline, even though that library should have fixed most issues like this.

$ jruby blah.rb
Type something: asdf
You have typed "asdf"
Getting string with readline: foo
You have choosen "foo"
Type something: something^M^M^M^M^M^M

We will want to investigate this in 9.4.1.

I suspect the current behavior is likely an undiscovered bug in the io-console library, but forcing CRuby to use reline and our version of io-console does not reproduce the issue. 🤔

Punted to 9.4.2, just didn't get around to it. Someone else could possibly confirm what is changing in the TTY with reline, so I have a place to start.

I doubt we will ever see a fix to jline so the 9.3 line probably will have to live with this bug for a while.

Ah, actually we need to confirm if we are properly shutting down jline as mentioned in jline/jline2#210. If the shutdown logic suggested there works properly, then the jruby-readline library just needs to add a shutdown hook to call it.

I'm going to kill this one. The path forward is using reline with minimal native calls in io/console to handle most of the terminal tweaking. jline is largely dead as far as maintenance and we don't ship it anymore.