Re: fg via keybind modifies tty settings

[David Moberg]

Den ons 16 okt. 2024 17:43Chet Ramey <chet.ramey@case.edu> skrev:

> 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/


So there is no good way of solving this and therefor no way to solve it at
all?
I guess fish and zsh might be misbehaving in other ways, but they seem to
handle this detail better. I wonder what the tradeoff is.