Re: fg via keybind modifies tty settings

[Chet Ramey]

On 10/13/24 12:10 PM, David Moberg wrote:
> A new issue popped up with these changes. After second time of suspend and
> foreground with binding, the tty will not react to control keys but instead
> print them on the prompt.

In general, this can't work, given a well-behaved process like vim that
modifies the tty settings.

> | start vim
>    ctrl-z (to suspend)
>    ctrl-a (bound to `fg` to bring to foregound)
>    ctrl-z (to suspend a 2nd time)
>    # broken state (but I dont see anything changed in the output of `stty
> -a`)
>    # ctrl-a prints ^A (instead of executing fg)
>    # <UP> prints ^[[A (Instead of invoking history)
>
> Issue 1: control codes are printed to prompt

The important thing to remember is that the shell saves the tty settings
when it starts up and after each forked command exits, so it can set them
for child processes. This is how it can make stty settings stick while
still setting the terminal for readline. It doesn't do this if it's running
a command from a readline key binding.

It restores the terminal attributes to these saved settings after a process
exits due to a signal or stops so a misbehaving process doesn't corrupt
the terminal.

Let's use the following shorthand:

R = tty settings for readline (-icanon)
V = tty settings for vim (-icanon)
S = tty settings shell inherited or saved (icanon)

Here's what happens:

shell saves tty settings S
readline sets tty settings R
readline reads "vim ...\n"
shell sets tty to S
shell execs vim
vim saves tty settings S

vim sets tty settings V
vim reads ^Z
vim sets tty settings S (saved)

vim sends itself SIGTSTP
shell catches stopped child

shell sets tty settings S (the saved tty settings because the process stopped)
readline sets tty settings R
readline reads ^A
shell sends SIGCONT due to running `fg' from the `bind -x' binding
        - this is where the shell used to save the terminal settings again
          for later resetting, but it no longer does due to your previous
          report, so S is unchanged

vim gets SIGCONT
vim sets tty settings V
vim reads ^Z
vim sets tty settings S (saved)

vim sends itself SIGTSTP
shell catches stopped child

shell sets tty settings S (saved tty settings because the process stopped)
        - but it wouldn't matter because vim already set them to S

readline is still active because this was all a key binding

Now readline thinks the settings are R, but the settings are S.


> Issue 2: typing `echo<TAB>` tab completes correctly to `echo`, but this
> debug print is printed:
> ```
> bash: DEBUG warning: cpl_reap: deleting 33287

That's a red herring, the programmable completion you're using uses a
coprocess.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/