keyboard behaves poorly after ctrl-c

[cbm755]

After I press control-C, keyboard input is... well messed up. Like some keys generate ascii junk, non-deterministically. Especially the "r" key and the arrow keys.

octave:1> ver
----------------------------------------------------------------------
GNU Octave Version: 5.1.0 (hg id: d05d6eebde10)
GNU Octave License: GNU General Public License
Operating System: Linux 4.20.16-200.fc29.x86_64 #1 SMP Thu Mar 14 15:10:22 UTC 2019 x86_64
----------------------------------------------------------------------
Package Name  | Version | Installation directory
--------------+---------+-----------------------
     control  |   3.1.0 | /home/cbm/.local/share/octpkgs/5.1.0/control-3.1.0
          io  |  2.4.12 | /home/cbm/.local/share/octpkgs/5.1.0/io-2.4.12
 packajoozle  |   0.1.0 | /home/cbm/.local/share/octpkgs/5.1.0/packajoozle-0.1.0
  statistics  |   1.4.0 | /home/cbm/.local/share/octpkgs/5.1.0/statistics-1.4.0
octave:2> a = 42
a = 42
octave:3> % going to press Ctrl-C
octave:3> 
[~] 
octave:3> �%�
 parse error:

  invalid character '�' (ASCII 254)

>>> ��
    ^

octave:3> % pressed and ok if I t�
yparse error:

  invalid character '�' (ASCII 254)

>>> �
    ^

octave:3>�
%parse error:

  invalid character '�' (ASCII 254)

>>> �
    ^

octave:3�
-bash: fg: %: no such job
[~] ps�
�  PID TTY          TIME CMD
 9009 pts/32   00:00:00 bash
 9173 pts/32   00:00:00 bwrap
 9182 pts/32   00:00:01 octave-gui
 9228 pts/32   00:00:00 ps
[~] a = 42
bash: a: command not found...
[~] 

Also, when I press Ctrl-C, I see my BASH prompt, but Octave is still running. Not really clear when my commands were going to bash and when to Octave.

Is bwrap doing some filtering on my keycodes? Feels like I've Ctrl-C'd something other than Octave...

[mtmiller]

This is about running Octave in the terminal without --gui, right?

I've seen the same thing since I started using Flatpak, and I don't know the cause.

I did just notice that

flatpak run --command=bash org.octave.Octave
exec octave

fixes this. So it's not a general Flatpak problem.

[cbm755]

I think so: I was doing flatpak run org.octave.Octave

And yes that suggestion works around it, thank you.

I've never been totally happy with Octave's Ctrl-C behaviour (every now and then I get lockups or races etc, usually involving tightloops with plotting and banging repeatedly on ctrl-c: I think its generally better lately). Anyway, was never as regular as this... Of course, IIRC, Matlab's Ctrl-C isn't optimal either (can't Ctrl-C out of compiled routines for example).

[cbm755]

This reminds me somewhat of the old says where ctrl-S would f^*kup my terminal and I had to remember some terminal reset command to fix it...? Possibly related?

[cbm755]

Or maybe it was binary files, like https://unix.stackexchange.com/questions/79684/fix-terminal-after-displaying-a-binary-file

[cbm755]

Nope, reset does not fix it.

[mtmiller]

A few small findings to report, but probably nothing that points to an answer yet.

When Flatpak runs octave-cli in a terminal, both bwrap and octave-cli have their stdin opened to the pseudoterminal device. There is also a xdg-dbus-proxy running with its own bwrap, also reading from the same pseudoterminal. All 3 bwraps as well as octave-cli are marked as being in the terminal foreground (a + in the process state reported by ps ax).

23240 pts/4    Ss     0:00  \_ /bin/bash
32339 pts/4    S+     0:00  |   \_ bwrap --args 35 /app/bin/octave-cli
32350 pts/4    S+     0:00  |       \_ bwrap --args 35 /app/bin/octave-cli
32352 pts/4    Sl+    0:01  |           \_ /app/bin/octave-cli
32346 pts/4    S+     0:00 bwrap --args 35 xdg-dbus-proxy --args=37
32347 pts/4    Sl+    0:00  \_ xdg-dbus-proxy --args=37

After Ctrl+C results in a SIGINT, xdg-dbus-proxy has exited, octave-cli and its bwrap are still running, but is no longer in the terminal foreground. It hasn't been sent a signal to put it in a background state, it is still "running". But all input seems to me to be going to bash.

23240 pts/4    Ss+    0:00  \_ /bin/bash
32350 pts/4    S      0:00 bwrap --args 35 /app/bin/octave-cli
32352 pts/4    Sl     0:01  \_ /app/bin/octave-cli

Several terminal device options have been unset: ICRNL, ICANON, ECHO, and VLNEXT. I can restore my original terminal state with stty echo icanon icrnl lnext ^V. And the only way I can stop Octave is with SIGKILL.

[mtmiller]

For comparison, if I run bash instead with flatpak run --command=/bin/bash org.octave.Octave, I get

23240 pts/4    Ss     0:00  \_ /bin/bash
 8319 pts/4    S      0:00  |   \_ bwrap --args 34 /bin/bash
 8330 pts/4    S      0:00  |       \_ bwrap --args 34 /bin/bash
 8332 pts/4    S+     0:00  |           \_ /bin/bash
 8326 pts/4    S      0:00 bwrap --args 32 xdg-dbus-proxy --args=37
 8327 pts/4    Sl     0:00  \_ xdg-dbus-proxy --args=37

Notice the lack of + on every process except for the active /bin/bash. This looks like the way it should be working, only the active running program is set as the foreground process for the terminal and is the only one that receives terminal-initiated signals.

If I instead run flatpak run --command=/bin/bash org.octave.Octave -c "sleep 10", I get

23240 pts/4    Ss     0:00  \_ /bin/bash
10081 pts/4    S+     0:00  |   \_ bwrap --args 35 /bin/bash -c sleep 10
10092 pts/4    S+     0:00  |       \_ bwrap --args 35 /bin/bash -c sleep 10
10094 pts/4    S+     0:00  |           \_ sleep 10
10088 pts/4    S+     0:00 bwrap --args 35 xdg-dbus-proxy --args=37
10089 pts/4    Sl+    0:00  \_ xdg-dbus-proxy --args=37

This time, all processes are terminal foreground processes.

So the question is why are bwrap and xdg-dbus-proxy set as foreground processes when Octave runs as the first program in the Flatpak container?

[j-tai]

This is still an issue for me. @mtmiller's workaround seems to fix it, though. I made it permanent by putting this in my bashrc:

alias octave='flatpak run --command=bash org.octave.Octave --norc -i -c '\''exec octave "$@"'\'' -'