bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Chet Ramey
Subject: Re: Cursor jumps to leftmost column on trap ... SIGALRM
Date: Fri, 4 Feb 2022 13:19:37 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1

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.

When readline gets the SIGALRM, it cleans up the terminal, resets the
signal handler to what it was when it was called, and resends the SIGALRM
to the current process. Part of that cleaning up the terminal involves
taking it out of bracketed paste mode.

The escape sequence that takes the terminal out of bracketed paste mode
ends with carriage return (\r). Ironically, this is needed to ensure that
the Linux terminal driver doesn't get confused about the physical cursor
position.


        So far I've watched this behavior only with SIGALRM.

It would probably happen with any signal for which readline installs a
handler.

For this case, since the signal handler doesn't do anything, it's enough to
set readline's internal idea of the cursor position after writing the
disable-bracketed-paste key sequence. The cursor will stay at position 0
until you do something that requires a redisplay, then the right thing will
happen.

In the general case, the application's signal handler can do just about
anything, and the state of the display is indeterminate. Readline can't
know.

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.

Chet


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]