Re: Fw: zsh POSIX_TRAPS option

[Jilles Tjoelker <jilles@xxxxxxxx>]

On Mon, Oct 11, 2010 at 08:16:52AM -0700, Bart Schaefer wrote:
> On Oct 11,  9:42am, Jilles Tjoelker <jilles@xxxxxxxx> was quoted
> } by Peter W. Stephenson:

> } Regarding the POSIX_TRAPS option, I can't help but wonder if making a
> } difference between f() { ... } (POSIX functions) and function f { ... }
> } (ksh functions) instead of adding more and more options would make
> } things less complex.

> That could have been a good idea when the "function" keyword was first
> introduced, but we now have years of treating them equivalently to
> think about.  (Also, whether functions have their own traps is based
> on the LOCAL_TRAPS option, not the POSIX_TRAPS option, except for the
> special case of the EXIT trap.)

> In particular there's the problem of autoloaded functions.  We already
> have several potentially confusing tricks to designate KSH_AUTOLOAD and
> to define the of function correctly in the event the file is loaded
> under the wrong regimen.  Having an additional behavior that changes
> depending on these circumstances would seem to me more complex rather
> than less, particularly if there's no way to test for that behavior.

Yes :(

> } In ksh93, ksh functions have their own traps, while POSIX functions
> } share the invoker's traps.

> This is suddenly seeming familiar.  There may have been discussion of
> changing zsh semantics of "function f" vs. "f()" at some earlier time,
> but I have no idea how to do an efficient list archive search for it.

> I have only a year-old version of mksh to conveniently play with.  What
> does "have their own traps" imply during function execution about traps
> that were set before the function was entered, when the function does
> NOT redefine them?

You need ksh93 for this, as mksh does not (yet) implement this feature.
The basic idea is that the function is treated much like a separate
process: if the signal occurs and there is no trap handler in the
function environment, the function is aborted and the parent's trap is
taken.

There is additional magic if the exit and return special builtins are
used without parameter in a a function environment's trap handler:
the outer environment's trap handler is executed as well; in the case of
return, execution then continues (unless a trap handler exited).

Although more complicated to implement, this seems to make more sense
than simply saving and restoring the traps, especially with ksh93's
static scoping which shields function g from function f's variables if f
calls g.

-- 
Jilles Tjoelker