Fw: zsh POSIX_TRAPS option

Fw: zsh POSIX_TRAPS option

[Peter Stephenson]

Date: Sat, 9 Oct 2010 14:54:17 +0200
From: Jilles Tjoelker <jilles@stack.nl>
To: Peter Stephenson <pws@csr.com>
Subject: zsh POSIX_TRAPS option


Hi,

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. In ksh93, ksh functions have their own traps, while
POSIX functions share the invoker's traps.

ksh93 does not support function f() { ... } (a stupid bashism), but mksh
does, treating it as a POSIX function.

-- 
Jilles Tjoelker


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Fw: zsh POSIX_TRAPS option

[Bart Schaefer]

On Oct 11,  9:42am, Jilles Tjoelker <jilles@stack.nl> 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.

} 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?

Re: Fw: zsh POSIX_TRAPS option

[Jilles Tjoelker]

On Mon, Oct 11, 2010 at 08:16:52AM -0700, Bart Schaefer wrote:
> On Oct 11,  9:42am, Jilles Tjoelker <jilles@stack.nl> 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