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

[Chet Ramey]

On 3/3/14 7:47 AM, konsolebox wrote:
> On Wed, Feb 19, 2014 at 11:01 PM, Chet Ramey <chet.ramey@case.edu
> <mailto: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.

I made no changes in this area.  It was far too late in the bash-4.3
release cycle.  There is commented-out code in lib/sh/zread.c for you
to play around with, but it is not enabled by default in bash-4.3.

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/