Re: signal handling

[Ralf Wildenhues]

* Bob Proulx wrote on Mon, Nov 12, 2007 at 10:52:45PM CET:
> Ralf Wildenhues wrote:
> > Ahh.  More head scratching.  I'd appreciate if somebody could
> > look over these two proposed patches to see if what I think how
> > signals ought to work makes sense.
> 
> This one I think is the opposite of what it needs to be.
> 
> > +    trap '' $signal
> 
> I think that should be <trap - $signal> instead.  But of course that
> was the topic of the discussion:
> 
> > For one: the "trap ''" does what I want on GNU/Linux: avoid infinite
> > recursion, and cause the whole test suite to be interrupted upon ^C.[1]
> > But I'm not sure if, on some other system, it may just cause the
> > interrupt to be ignored completely.
> 
> On my GNU/Linux system using <trap '' $signal> causes the signal to be
> ignored.  I believe that is the documented behavior.  Isn't it?  If
> that is what is desired then okay.  But it looks to me that the signal
> should be return to the default value before the kill of itself.  That
> would be the same as the perl part of the patch.

Yes.  What I don't understand is why things still seemed to work for me
with trap ''.

> I think the root of the infinite recursion problem is the trap of
> SIGPIPE.  I think if signal 13 is left not trap'd then no infinite
> recursion would happen and no need to ignore the signal later.  I
> assume that it is sigpipe that is the reason it needs to be ignored.

Cool idea.  I think I only got it while completely forgetting to change
the trap, so it would just re-invoke itself over and over again due to
the `kill'.

> Seeing both the trapping of SIGPIPE and the ignoring of it later
> triggered alarm bells in my head.
*snip*

Thanks for the nice description.

> This is why whenver I see SIGPIPE trap'd in scripts I *always* get
> nervous about it and challenge the reason for it being there.
*snip*

> Looking into the archives I see this in the previous proposal:

Which is all just copied from Autoconf's _AC_INIT_PREPARE, so it's the
code that most every `configure' script uses.

> This part caught my eye.
> 
> +trap 'exit_status=$?
> +...
> +  exit $exit_status
> +' 0
> 
> Is there a purpose to this extra layer of exit return code setting?
> Shouldn't that simply be left untouched in the trap EXIT handler?  Do
> shells exist that respect an exit with a value in an EXIT handler?  My
> testing shows that it is ignored by the shell but I did not dig around
> on weird systems.

I think that pays due to the portability discussion of `exit' and, more
importantly, `trap' in
  info Autoconf "Limitations of Builtins"

and yes, it seems to only matter for some shells.

Cheers,
Ralf