Re: signal handling

[Bob Proulx]

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.

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.

Seeing both the trapping of SIGPIPE and the ignoring of it later
triggered alarm bells in my head.  Let me describe the case I am
concerned about.  In other scripts I have found problems with people
doing this following bad thing.

  trap 'echo caught a signal; exit 1' 2 13

Since SIGPIPE was being trapped and output generated it was causing a
cascade SIGPIPE due to the new output which trapped and caused more
output and repeatedly called until a stack overflow stopped the
otherwise infinite loop.  And this only happened when a user Ctrl-C'd
the application generating a SIGINT.

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.

> Anyway, with these two patches it seems to be reliably possible to
> stop `make check' with one Control-C.

Hard to argue with results!  :-)

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

+trap 'exit_status=$?
+  cd "$curdir"
+  case $exit_status,$keep_testdirs in
+  0,)
+    chmod -R a+rwx $testSubDir > /dev/null 2>&1
+    rm -rf "$testSubDir" ;;
+  esac
+  test "$signal" != 0 &&
+    echo "$as_me: caught signal $signal"
+  echo "$as_me: exit $exit_status"
+  exit $exit_status
+' 0
+for signal in 1 2 13 15; do
+  trap 'signal='$signal'; { (exit 1); exit 1; }' $signal
+done
+signal=0

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.

Bob