From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15210 invoked by alias); 11 Oct 2010 15:17:29 -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: 28342 Received: (qmail 15329 invoked from network); 11 Oct 2010 15:17:26 -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,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <101011081652.ZM18151@torch.brasslantern.com> Date: Mon, 11 Oct 2010 08:16:52 -0700 In-reply-to: <20101011094241.17796aaa@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Fw: zsh POSIX_TRAPS option" (Oct 11, 9:42am) References: <20101011094241.17796aaa@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: "Zsh Hackers' List" Subject: Re: Fw: zsh POSIX_TRAPS option Cc: Jilles Tjoelker MIME-version: 1.0 Content-type: text/plain; charset=us-ascii 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. } 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?