From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23160 invoked by alias); 15 Oct 2010 13:56:25 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28350 Received: (qmail 6507 invoked from network); 15 Oct 2010 13:56:22 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at spf.stack.nl designates 131.155.140.104 as permitted sender) Date: Fri, 15 Oct 2010 15:47:47 +0200 From: Jilles Tjoelker To: Bart Schaefer Cc: Zsh Hackers' List Subject: Re: Fw: zsh POSIX_TRAPS option Message-ID: <20101015134747.GA56014@stack.nl> References: <20101011094241.17796aaa@pwslap01u.europe.root.pri> <101011081652.ZM18151@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <101011081652.ZM18151@torch.brasslantern.com> User-Agent: Mutt/1.5.20 (2009-06-14) On Mon, Oct 11, 2010 at 08:16:52AM -0700, Bart Schaefer wrote: > On Oct 11, 9:42am, Jilles Tjoelker 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