Re: localtraps

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Apr 26,  7:34pm, Peter Stephenson wrote:
} Subject: Re: localtraps
}
} The problem may be related to the fact that [zsh] executes traps
} from within the signal handler.  Other shells presumably wait for the
} handler to exit and execute the trap at the next obvious point

Normally it's the case that executing the trap from within the signal
handler means that you can't handle the same signal again before the
trap function has exited.  However, I think the only way to get the
behavior I'm seeing is that the "trap" command unblocks the signal
again, allowing it to be re-delivered before the handler finishes (at
least, on linux it looks that way).

Also, it's not universally true that zsh executes traps from inside
the handler; there *is* a queue of unfinished handlers maintained, for
circumstances where it's dangerous to run shell code, e.g., while some
other shell code is executing and possibly calling malloc().  It's only
when the shell is idle that zsh runs the trap in the handler.

} However, I've tried this in some recent versions of zsh (4.2.0 and
} 4.3.0-dev-1, which is a moving target) and it seems to do what I think
} you want... abort the programme when you hit ^C twice quickly, otherwise
} continue.  So I'm not sure what you're doing wrong.

There's definitely something odd about the behavior of zsh here.  For
example, given:

    setopt localtraps
    TRAPINT() { echo OUTER; trap "echo INNER" INT; sleep 2 }

On the first ^C at the PS1 prompt, OUTER is printed, and no new prompt
is drawn.  If I press ^C again within 2 seconds, then a blank line (no
idea why) and INNER is printed, but still no new prompt.  Note that no
shell loop is involved, this with the shell merely waiting for input.

Every subsequent ^C, no matter how long I wait, prints INNER, up until
a newline is pressed, at which point a new prompt is drawn.  Once the
prompt is redrawn, subsequent interrupts do nothing at all (neither
OUTER nor INNER is printed).  However, "trap" with no argument still
shows the original TRAPINT function.

So localtraps eventually worked in the sense that the inner trap was
removed, but the outer trap was never reset in the signal handler.