Re: Bash 4.3 no longer handles traps when reading input with read

[konsolebox]

On Wed, Feb 19, 2014 at 11:01 PM, Chet Ramey <chet.ramey@case.edu> wrote:

> On 2/19/14 1:51 AM, konsolebox wrote:
>
> >     Bash-4.3 handles signals and traps when a read run by the read
> builtin is
> >     interrupted by a  signal.  I'm not  sure that's the best thing to do,
> >     since traps should really be run when commands finish, but we're
> going to
> >     try it.
> >
> >     Since bash-4.2, bash has installed its SIGCHLD signal handler with
> >     SA_RESTART, so a child death does not unexpectedly interrupt system
> calls.
> >     There were several bug reports concerning this.  So yes, SIGCHLD is
> >     special.
> >
> >
> > I'm not really able to comprehend the significance of SA_RESTART to
> SIGCHLD
> > that it could affect the signal and make it behave differently from the
> > other signals i.e. it can't be a good idea to allow interruption from it
> > when in a read builtin context, but could it be possible that we allow it
> > when not in posix mode? Probably it's about the variable posixly_correct.
> > If we can allow at least just one interruption to happen maybe with the
> > help of the variable running_trap it would really be good enough.
>
> SIGCHLD is different from other signals in that it can arrive at any time
> without user intervention. Say you run a background process that exits
> during a call to the read builtin.  Should it interrupt the read?  What
> would be gained by having system calls return errors because bash reaps a
> child?  Should it interrupt the read only if there is a trap set?
>
> There's a way to do what you want, but the question is whether or not the
> demand is sufficient to make SIGCHLD traps run when other traps would not.
>

I tried to use my script again with the new release of bash (4.3). Almost
every signal was allowed besides SIGCHLD (17). SIGALRM (19) seems
reasonable not to be included since it's used by read. SIGKILL (9) and
SIGCONT (19) which I excluded from it I doubt are reasonable to be caught.

#!/bin/bash

catcher() {
    echo "Interruption allowed."
}

for (( I = 1; I <= 31; ++I )); do
    [[ I -ne 9 && I -ne 19 ]] && trap catcher "$I"
done

(
    for (( I = 1; I <= 31; ++I )); do
        [[ I -ne 9 && I -ne 19 ]] || continue
        sleep 1s
        echo "Sending $I."
        kill -s "$I" "$$"
    done
) &

echo "Interacting."

until read -t 1; do
    continue
done

--------------------

# bash-4.3 temp.sh &>log.txt
Interacting.
Sending 1.
Interruption allowed.
Sending 2.
Interruption allowed.
Sending 3.
Interruption allowed.
Sending 4.
Interruption allowed.
Sending 5.
Interruption allowed.
Sending 6.
Interruption allowed.
Sending 7.
Interruption allowed.
Sending 8.
Interruption allowed.
Sending 10.
Interruption allowed.
Sending 11.
Interruption allowed.
Sending 12.
Interruption allowed.
Sending 13.
Interruption allowed.
Sending 14.
Sending 15.
Interruption allowed.
Sending 16.
Interruption allowed.
Sending 17.
Sending 18.
Interruption allowed.
Sending 20.
Interruption allowed.
Sending 21.
Interruption allowed.
Sending 22.
Interruption allowed.
Sending 23.
Interruption allowed.
Sending 24.
Interruption allowed.
Sending 25.
Interruption allowed.
Sending 26.
Interruption allowed.
Sending 27.
Interruption allowed.
Sending 28.
Interruption allowed.
Sending 29.
Interruption allowed.
Sending 30.
Interruption allowed.
Sending 31.
Interruption allowed.

--------------------

I'm not sure about demand for the use of the signal. Some might find making
use of it really useful I hope but certainly it would have been useful for
my part. I have had this free project which started in 2004 which I use
most of the time to play audio files. Since bash would no longer entertain
handling traps when a SIGCHLD signal is caught in a context of a read
session playing another file after the player ends would wait until the
read timeout is reached. Using a loop would still give a 1 second gap
between plays and would consume much CPU time and even much more if I
shorten the interval. Once I had tried to patch it and I found my laptop
heating up more quickly because of it. This becomes the very reason why I
no longer find continuing the project to be practical. I actually already
lost the urge to continue developing it the time I knew about out the
changes in 4.3.

Just in case the project I refer to is named PlayShell [
http://sourceforge.net/projects/playshell/]. Its last form has been working
really well already in bash 4.2, besides the crashing which I thought would
be fixed and not changed in 4.3. Despite the crashing it already has a way
to uninterruptingly restart itself when it happens.