Re: trap - INT in subshell

[P.Stephenson@xxxxxxxxxxxxx]

schaefer@xxxxxxxxxx wrote:
> I wrote about trappint SIGINT in subshells:
> } % trap '' INT
> } % (trap - INT; sleep 2)
> } ^C			# nothing happens.
>
> Zsh is apparently also blocking the signal, which it shouldn't need to
> if the handler has really been set to SGN_IGN; I'd suggest you try to
> find out why it is being blocked before you unblock it.  The blocking
> may have nothing to do with the trap, except by this accident of bad
> interaction between them.

Well, I removed both the holdintr() I talked about, just after the
shell forked in execcmd(), and the noholdintr, and sure enough that
stopped the behaviour above.  However, it also made children
interruptible:

% trap '' INT
% sleep 2
^C
%	# whoops

This is despite the fact that zsh appears happily to be setting
SIG_IGN for SIGINT in settrap() in signals.c, so the holdintr() is
clearly necessary at the moment.  This doesn't square with your
remarks above, so maybe that needs some investigation by the
signalling department.

However, it does make me pretty confident that the patch I posted does
the right thing given the current code.

> } Anyway, if I revise the previous patch to unblock ^C when the trap is
> } unset
> 
> This sounds right.  My only concern is that it might unblock the signal
> too soon and introduce a race condition; I haven't looked at zsh signal
> handling code in many months.

I wondered about this, but the code should only be executed during a
`trap', `disable' or `unfunction'/`unhash' builtin, so I don't think
this is an issue.  None of the holdintr() in the code appear to
conflict with this.

> } and change the printjob() code so that it only sets errflag on
> } a SIGINT if that's not being ignored, the code works.
> 
> This part I'm less sure about, but I think it's right.  That's the code
> that's trying to propagate the interrupt up to zsh when a child process
> is what actually caught the signal?
> 

This was part I was actually more sure about:  as you way, it marks an
error within zsh when the child died with SIGINT (and only then).
The new test is only going to apply when zsh was ignoring SIGINT but a
child wasn't, i.e. under just the cirumstances I'm fixing up.  (Well,
that's my claim.)

So I think the patch is O.K. (braces notwithstanding).

-- 
Peter Stephenson <P.Stephenson@xxxxxxxxxxxxx>  Tel: +44 1792 205678 extn. 4461
WWW:  http://python.swan.ac.uk/~pypeters/      Fax: +44 1792 295324
Department of Physics, University of Wales, Swansea,
Singleton Park, Swansea, SA2 8PP, U.K.