Re: Problems with trap handling?

[Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxxxxx>]

Sven Wischnowsky wrote:
> Bart Schaefer wrote:
> > function tst() {
> >   trap return INT 
> >   read -q xx'?Type ^C here: '
> >   echo You should not see this.
> > }
> > 
> > Execute in 3.1.6-dev-16 and type ^C.  Note that you don't leave the "read"
> > prompt.  Type any plain character; now "read" returns, and the function
> > aborts as if interrupted.
> 
> In this incanartion read ends up in read1char() which explicitly does
> *not* stop if the read returns with errno==EINTR. So I guess someone
> had a reason for doing this way.
> 
> We could either test retflag/breaks/contflag there or give it a flag
> that says to stop in case of EINTR and which would be set by bin_read
> (via getquery()).

I think the answer is it should be testing more flags at this point:
whatever's making the function return (i.e. retflag) should make the read
return, too. It's certainly correct that EINTR shouldn't make it return ---
the problem was that the query aborted if, say, a background job exited,
and as far as I can see the same issue applies to any call to read1char().
It's quite possible the same issue comes up at umpteen other places in the
code, alas.

-- 
Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxxxxx>