Re: Bash spews bracketed-paste escape sequences when handling signal.

[Kaz Kylheku]

On 2024-12-14 11:36, Chet Ramey wrote:
> On 12/14/24 12:40 PM, Kaz Kylheku wrote:
>> Hi!
>>
>> I first ran into this issue on MacOS using the Homebrew build of Bash 5 
>> (BASH_VERSION "5.2.37(1)-release").
>>
>> When a trap is installed for a signal, and delivered, Bash sends characters 
>> to the terminal which move the cursor.
> 
> It does not; readline does. This turns out to make a difference.

Yes; and that is consistent with the issue having a readline config workaround.

Pretend I wrote "bash process" not "code in the bash executable itself".

>> If you do not have "trap : ALRM" then this doesn't happen.
> 
> Because SIGALRM is a terminating signal that kills the shell.

But no; I mean the shell keeps running in that case. Try it:

  $ kill -ALRM $$
  $ # didn't die

For some other signals like VTALRM or USR1, it does terminate as you say.

Furthermore, if the Bash trap for ALRM is not installed, then
the readline behavior in question (emission of terminal sequences)
doesn't occur.

Since "trap : ALRM" is a Bash feature and not a readline feature,
it's hard to escape the conclusion that Bash is somehow acting as an
enabler for the behavior.

The right fix may be to stay away from SIGALRM, since readline
clearly uses it for something.

Disabling bracketed paste is probably a bad workaround; what if
some Basta user wants that to work?

With signals other than SIGALRM, the code has to be careful; if it
ever happens that the signal is delivered without the trap being
in place, Bash will die.