On 2024-12-18 12:48, Chet Ramey wrote:
> On 12/18/24 1:27 PM, Kaz Kylheku wrote:
>
>> What remains is the question why I somehow cannot get my
>> stuff to work with a different signal like SIGUSR1 or SIGVTALRM.
>>
>> Bash will not take them while it's sitting in the call to readline.
>
> Something is indeed messed up in your execution environment.
>
> Let's try killing an interactive shell sitting in readline() from another
> terminal:
>
> $ echo $BASH_VERSION
> 5.2.37(6)-release
> $ trap
> $ echo $$
> 30762
> User defined signal 1: 30
>
> [shell terminates]
>
> Now let's try killing an interactive shell that's not sitting in readline()
> with the same fatal signal:
>
> $ echo $BASH_VERSION
> 5.2.37(6)-release
> $ trap
> $ kill -USR1 $$
> User defined signal 1: 30
>
> [shell terminates].
Right; I didn't make the wrong claim that SIGUSR1 isn't fatal. I made
that wrong claim only about SIGALRM, and retracted that already.
The real issue is this:
Let's work with SIGUSR1 first:
$ trap 'echo USR1' USR1
$ kill -USR1 $$
USR1
$ kill -USR1 $$
USR1
So far, so good! Now let's sit at the prompt, while sending the signal
from a background process:
$ while sleep 1; do kill -USR1 $$; done &
[1] 22261
$ fg
USR1
while sleep 1; do
kill -USR1 $$;
done
^C
USR1
I waited 20 seconds before typing "fg". Nothing!
Now, let's try it with SIGALRM:
$ trap 'echo ALRM' ALRM
$ while sleep 1; do kill -ALRM $$; done &
[1] 21882
$ ALRM
ALRM
ALRM
ALRM
ALRM
ALRM
ALRM
ALRM
ALRM
The "echo ALRM" commands go off like clockwork, every second.
Most likely because of the way Readline treats signals, SIGARLRM ends up
"blessed" for this purpose. By dumb luck, I had picked the winning signal;
it was the first one I reached for.
I understand that Bash will die if you send a SIGUSR1, and it
has no trap set up for it; but when it does have a handler set up,
it seems that Readline may be blocking the signal (perhaps via the sigprocmask
or whatever). I probably won't be digging into it more.
