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

[Chet Ramey]

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.

(BTW, this doesn't have anything to do with Bash's posix mode.  The posix
standard that applies here is the system interfaces one, not the shell
one.)

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/