From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20692 invoked from network); 23 Nov 2022 08:12:49 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 23 Nov 2022 08:12:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:Subject:Cc:To:From:Date: References:In-Reply-To:Message-Id:Mime-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=GiXh8nxzgdtWVi80DY2jl1NGQNPg6EUpN2Tps42qPiY=; b=T78irSjk/6gWb3R9BfNuGCuoeX NvlrKTzkamm1Kq2CrIeBWO+IeY1JXCZsVa3ThVqRNjVn84n6A/QQSgz2oLmbKNpUSdEP5FbesNUxl RT+kNbrA8zQaUaaTPm77Ei76wwY+bAWLZGdqESUZgUrP7O1Ys3CKt2YiDT6DTENU98oqYzfG62gL0 UgmRnYGqb88rtCQniSa8iN96qwpMdF4e4xJOG86+ve6NSvIwWaB2ZdJwMdQbR60ztTDHeTgihjMeE llVQRRG6u5NHUK3040OrGuFv3CVDBcX1FyGe7sGwTndwogxYnN8+I+WRhC35YAhEQ0FLqnyFNeICF aKQm/3fw==; Received: by zero.zsh.org with local id 1oxksC-0000q9-W8; Wed, 23 Nov 2022 08:12:49 +0000 Received: by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1oxkrc-0000Ut-GQ; Wed, 23 Nov 2022 08:12:12 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id 7BA2C27C005A; Wed, 23 Nov 2022 03:12:10 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute2.internal (MEProxy); Wed, 23 Nov 2022 03:12:10 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedriedtgdduudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderreejnecuhfhrohhmpefnrgif rhgvnhgtvgcugggvlhojiihquhgviicuoehlrghrrhihvhesiihshhdrohhrgheqnecugg ftrfgrthhtvghrnhepleekheejgfdufeegkeeugedugefhvedvleejheeiueffheevjefg heethfduvefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheplhgrrhhrhihvodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeh udekjeejtdegqdduudelvdejfeekhedqlhgrrhhrhihvpeepiihshhdrohhrghesfhgrsh htmhgrihhlrdgtohhm X-ME-Proxy: Feedback-ID: iaa214773:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 296ED31A0063; Wed, 23 Nov 2022 03:12:10 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead Mime-Version: 1.0 Message-Id: In-Reply-To: <1563682955.1031478.1669112257901@mail.virginmedia.com> References: <230a78bb-fa97-4f3a-94a2-86982316274b@app.fastmail.com> <1563682955.1031478.1669112257901@mail.virginmedia.com> Date: Wed, 23 Nov 2022 03:11:49 -0500 From: =?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= To: "Peter Stephenson" Cc: zsh-workers@zsh.org Subject: Re: [PATCH] Fix ERR_EXIT behavior in function calls and "always" statements Content-Type: text/plain X-Seq: 51031 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: On Tue, Nov 22, 2022, at 5:17 AM, Peter Stephenson wrote: > On the whole I think keeping anonymous functions behaving like other functions > is probably sensible, though we could draw better attention to this unusual > degree of consistency somewhere in the documentation. > > I don't think there's a killer argument for this but if you're using an > anonymous function it's because you need some form of function behaviour and > my own inclination would be to continue to provide essentially the whole of it, > hopefully also limiting special cases in the source code. There would certainly be value in permitting set -e foo() { cmd1; cmd2; cmd3 } foo unset -f foo to be simplified to set -e () { cmd1; cmd2; cmd3 } while maintaining the same early-exit behavior. That consistency might be more useful than strict adherence to the syntax-based logic of POSIX "set -e". Plus, as Bart noted, the (...) exception has already set a precedent for special treatment. -- vq