On Fri, 4 Feb 2022 13:19:37 -0500 Chet Ramey <chet.ra...@case.edu> wrote:
> On 2/4/22 9:54 AM, Markus Schwarzenberg wrote: > > > Bash Version: 5.1 > > Patch Level: 8 > > Release Status: release > > > > Description: > > The position of the cursor changes to the first column when > > bash, running inside xterm, receives the signal SIGALRM > > Thanks for the report. It's readline and bracketed paste. Interestingly, I can't reproduce the behavior myself on the following system (opensuse tumbleweed) Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fun> uname output: Linux XXXXXXX 5.15.12-1-default #1 SMP Wed Dec 29 14:50:16 UTC 2> Machine Type: x86_64-suse-linux-gnu Bash Version: 5.1 Patch Level: 12 Release Status: release [ ... ] > We can force a redisplay in the code that handles the return from the > signal handler. That, however, has its own problems. If the > application's signal handler doesn't do anything, forcing the cursor > to a new line and forcing a redisplay will result in duplicated > lines. (If we don't force a new line, we can potentially overwrite > output from the application's signal handler.) > > I'll have to think about it. I'd be happy with some command forcing redisplay, executed from within the handler as a workaround. Note: The example given in the bug description is just the simplest way to reproduce that behavior. Practically I've been using the SIGALRM handler for really a long period now (ca. 20 years). Usage: It's invoked from a xterm key binding and finally makes the running bash open a file guessed from the currently selected ls -l output line (or gcc error line, etc.). The observed readline behavior is quite new ( < 1 year). It didn't happen in older versions. Thanks, Markus Schwarzenberg
