Re: Cursor jumps to leftmost column on trap ... SIGALRM

[Markus Schwarzenberg]

On Fri, 4 Feb 2022 13:19:37 -0500
Chet Ramey <chet.ramey@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