* 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
