Re: fg via keybind modifies tty settings
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. Repeat-By: | 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) # prints ^[[A (Instead of invoking history) Issue 1: control codes are printed to prompt Issue 2: typing `echo` tab completes correctly to `echo`, but this debug print is printed: ``` bash: DEBUG warning: cpl_reap: deleting 33287 ``` My environment: I build bash for the first time today with `configure` `sudo make install`. And bash verision that I just built: `GNU bash, version 5.3.0(1)-beta (x86_64-pc-linux-gnu)` (launched from terminal running my previous bash version `GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)`) Den lör 12 okt. 2024 kl 10:04 skrev Lawrence Velázquez : > On Sat, Oct 12, 2024, at 2:22 AM, David Moberg wrote: > > So this kind of bugfix is not enough to ever trigger a new release on its > > own? (sounds wise) > > No, but Chet does periodically release particularly important fixes > as patches against the most recent release. (Those make up most of > the commits on the "master" branch.) > > > Is there any cadence to releases > > Not that I'm aware of. > > > or any other reason to expect a release at > > some point in the future? > > I believe Chet is getting ready to release 5.3 sooner than later. > > -- > vq >
Re: fg via keybind modifies tty settings
Has anyone been able to take a more deep look? Where in the bash source code would this happen? I learned that fish resets these kind of settings quite often. Den tis 24 sep. 2024 16:21Chet Ramey skrev: > On 9/20/24 7:23 PM, David Moberg wrote: > > > Bash Version: 5.2 > > Patch Level: 21 > > Release Status: release > > > > Description: > > When a process/job is suspended, foregrounded via ctrl-a as a > > keybinding for fg, and then > > suspended again, the tty will be in a surprising state where no > > input is seen (-echo) > > When the shell starts a job with `fg', it fetches the tty settings so it > can restore them if the job exits or stops due to a signal. That way, a > job that modifies the terminal settings, then crashes, doesn't leave the > terminal in an unusable state. > > When you run a command from a readline key binding, it still runs in the > context of readline obtaining a line from the keyboard -- it's just another > key binding, like C-f. Readline doesn't reset the tty settings to run the > binding, and bash doesn't reset them to run the command. > > When `fg' runs and starts the job, the shell fetches the tty settings as > usual, but they are the tty settings readline uses when it's reading input. > It assumes those are the `normal' settings. > > When vim stops due to the SIGTSTP, the shell restores what it thinks are > the normal tty settings -- the ones it fetched after readline modified > them. The difference you see between the `working' and `broken' settings > is what readline does so it can read input. > > I will see if this can be changed by having `fg' detect whether it's > being run from a key binding and not fetch the terminal settings in that > case. > > Chet > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >
Re: fg via keybind modifies tty settings
Thanks! I would have tried it immediately if I knew about it. I will see if I'm able to try it on Monday. :) So this kind of bugfix is not enough to ever trigger a new release on its own? (sounds wise) Is there any cadence to releases or any other reason to expect a release at some point in the future? Den lör 12 okt. 2024 08:02Oğuz skrev: > On Saturday, October 12, 2024, David Moberg wrote: > >> This link shows a big commit to bash. Is it merged to main/release? Can I >> try it out? >> > > You can clone the devel branch to try it out. The master branch is only > updated for releases and important patches. > > > -- > Oğuz > >
Re: fg via keybind modifies tty settings
Oh, is this already fixed? What am I looking at? This link shows a big commit to bash. Is it merged to main/release? Can I try it out? The commit message is long, does it fix several issues at once? Den lör 12 okt. 2024 07:29Lawrence Velázquez skrev: > On Sat, Oct 12, 2024, at 1:11 AM, David Moberg wrote: > > Has anyone been able to take a more deep look? > > > https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=254081c09767738833cdf161b4bc3feb1a51690a > > -- > vq >
Re: fg via keybind modifies tty settings
Den ons 16 okt. 2024 17:43Chet Ramey 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) > ># 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 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, CWRUc...@case.eduhttp://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.
Re: fg via keybind modifies tty settings
This happens for both vim and python3, I haven't tried with other applications. I'm not sure when readline and raw mode are activated, I would have to read up on that. Den sön 22 sep. 2024 02:39Martin D Kealey skrev: > Does this happen with any raw-mode application, or just vim? > > When using readline in Emacs mode, the terminal is necessarily in raw mode. > > I suspect what you're seeing is that 'fg' bound to a key is bypasses the > normal "exit readline" that would restore the settings. Then when vim exits > or is suspended, Bash notices that it's still in raw mode (-icanon), but > doesn't otherwise know the details of exactly how you want it cooked > (+icanon but what else?). > > I'll check on this when I get back to my PC. > > -Martin > > On Sat, 21 Sep 2024, 09:23 David Moberg, wrote: > >> Configuration Information [Automatically generated, do not change]: >> Machine: x86_64 >> OS: linux-gnu >> Compiler: gcc >> Compilation CFLAGS: -g -O2 -fno-omit-frame-pointer >> -mno-omit-leaf-frame-pointer -flto=auto -ffat-lto-objects >> -fstack-protector-strong -fstack-clash-protection -Wformat >> -Werror=format-security -fcf-protection -Wall >> uname output: Linux Tugge 6.8.0-45-generic #45-Ubuntu SMP PREEMPT_DYNAMIC >> Fri Aug 30 12:02:04 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux >> Machine Type: x86_64-pc-linux-gnu >> >> Bash Version: 5.2 >> Patch Level: 21 >> Release Status: release >> >> Description: >> When a process/job is suspended, foregrounded via ctrl-a as a >> keybinding for fg, and then >> suspended again, the tty will be in a surprising state where no >> input is seen (-echo) >> >> Repeat-By: >> | bind -x '"\C-a":"fg"' # bind C-A to perform fg >> vim # >> # Terminal still works >> stty -a > working.txt # store tty settings >> # Put vim in foreground again >> :q # Quit vim >> vim # Start a new vim session (*) >> # Terminal is broken >> stty -a > broken.txt# store tty settings >> #type text and no echo >> >> Dumping the tty configuration before and after the broken state >> reveals this diff after the >> second vim command above (*) has been executed: >> >> ```console >> $ diff working.txt broken.txt >> 4c4 >> < werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; >> --- >> > werase = ^W; lnext = ; discard = ; min = 1; time = >> 0; >> 6c6 >> < -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr >> icrnl >> ixon -ixoff >> --- >> > -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr >> -icrnl ixon -ixoff >> 9c9 >> < isig icanon iexten echo echoe echok -echonl -noflsh -xcase >> -tostop -echoprt >> --- >> > isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase >> -tostop -echoprt >> ``` >> >> The tty can get back into working state by running `stty sane`. >> >> By redoing the > sane> >> it can be seen that the >> terminal will only be broken after every second invocation. >> >> Similar issue(?) in fish that has been resolved: >> https://github.com/fish-shell/fish-shell/issues/2114 >> >> I have experienced the same weirdness with other applications than >> vim, for example python3. >> I have experienced the issue several terminals: Wezterm, xfce-4 >> terminal. >> >
fg via keybind modifies tty settings
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -flto=auto -ffat-lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wall uname output: Linux Tugge 6.8.0-45-generic #45-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 30 12:02:04 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.2 Patch Level: 21 Release Status: release Description: When a process/job is suspended, foregrounded via ctrl-a as a keybinding for fg, and then suspended again, the tty will be in a surprising state where no input is seen (-echo) Repeat-By: | bind -x '"\C-a":"fg"' # bind C-A to perform fg vim # # Terminal still works stty -a > working.txt # store tty settings # Put vim in foreground again :q # Quit vim vim # Start a new vim session (*) # Terminal is broken stty -a > broken.txt# store tty settings #type text and no echo Dumping the tty configuration before and after the broken state reveals this diff after the second vim command above (*) has been executed: ```console $ diff working.txt broken.txt 4c4 < werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; --- > werase = ^W; lnext = ; discard = ; min = 1; time = 0; 6c6 < -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff --- > -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon -ixoff 9c9 < isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt --- > isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt ``` The tty can get back into working state by running `stty sane`. By redoing the it can be seen that the terminal will only be broken after every second invocation. Similar issue(?) in fish that has been resolved: https://github.com/fish-shell/fish-shell/issues/2114 I have experienced the same weirdness with other applications than vim, for example python3. I have experienced the issue several terminals: Wezterm, xfce-4 terminal.
Re: fg via keybind modifies tty settings
Yes, if seems like the way to do this in bash. It's unfortunate because doing it with a binding is more elegant as it avoids polluting the terminal output and shell history. In hindight: should the changes that were made to bash due to this discussion, be reverted? The previous behavior was less annoying to me (maybe because I was used to it) Den mån 18 nov. 2024 19:49Chet Ramey skrev: > On 11/16/24 5:29 AM, David Moberg wrote: > > Ok, is there anything I can do on my user side to get desired behavior? > > (similar to running `stty sane` every time I send vim to the background.) > > As several others have suggested, a simple macro that clears the line, > saving the text on the kill ring for future yanking, and inserts `fg\n' > is probably the best. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >
Re: fg via keybind modifies tty settings
That looks very complicated, how do interpret that? And where/when to run it? Den lör 16 nov. 2024 16:48#!microsuxx skrev: > trap ' t=$? ; [[ $BASH_COMMAND != *'$'bashcmd* ]] && bashcmd=$BASH_COMMAND > ' debug ; PROMPT_COMMAND=' [[ $t == 148 && $bashcmd == vim* ]] && echo ye > && stty sane ' > > On Sat, Nov 16, 2024, 4:40 PM #!microsuxx wrote: > >> PROMPT_COMMAND=' [[ $? == 148 ]] && stty sane ' >> >> On Sat, Nov 16, 2024, 11:29 AM David Moberg wrote: >> >>> Ok, is there anything I can do on my user side to get desired behavior? >>> (similar to running `stty sane` every time I send vim to the background.) >>> >>> Den tis 12 nov. 2024 16:49Chet Ramey skrev: >>> >>> > On 11/10/24 7:14 PM, Martin D Kealey wrote: >>> > >>> > > Perhaps what's really needed is to make sure that "ordinary" commands >>> > bound >>> > > using bash -x are completely broken (so people won't try to use >>> them), >>> > > rather than almost working. >>> > >>> > `Ordinary' commands aren't broken. Programs like vim that modify the >>> > terminal settings, which are in the minority, are. >>> > >>> > -- >>> > ``The lyf so short, the craft so long to lerne.'' - Chaucer >>> > ``Ars longa, vita brevis'' - Hippocrates >>> > Chet Ramey, UTech, CWRUc...@case.edu >>> http://tiswww.cwru.edu/~chet/ >>> > >>> >>
Re: fg via keybind modifies tty settings
Ok, is there anything I can do on my user side to get desired behavior? (similar to running `stty sane` every time I send vim to the background.) Den tis 12 nov. 2024 16:49Chet Ramey skrev: > On 11/10/24 7:14 PM, Martin D Kealey wrote: > > > Perhaps what's really needed is to make sure that "ordinary" commands > bound > > using bash -x are completely broken (so people won't try to use them), > > rather than almost working. > > `Ordinary' commands aren't broken. Programs like vim that modify the > terminal settings, which are in the minority, are. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >
