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 29560 invoked from network); 21 Nov 2022 07:25:07 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 21 Nov 2022 07:25:07 -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=QPkuiqOY8lOVCHnkgL/l2/GtTNX7HUCHrtQOouFbBmE=; b=XPzjKZWI5FpxG3N2h2Yw6bxdpR pw7hmmhiXTJf1i4/PtTf0kdUFOs7zclwhfVfFlTZJql4fIgClgzJmeCS18ch6UCKdtzLJ9204Cg3v 1cS6deos3+hi8cNvH3VO5VE1Q6gsKMgmX+UBjSaLZtKNPPXjjQELPkwEElHzvJMZFmNVBDInION+Y 6nI6neZzXWd9fdVgwmDAk6U0nJ09JFJAAh4ld292KSaSso6x8x4hgezHVTDYNy44L3chweVjupEGL qCsMHV+ayEZoNsookaW9FzU8Ta21aj26VQzWoquDVf5OkO2s0fUgS/aGiMzlTT5brJ1ccPxcEl1lH Y00m1djQ==; Received: by zero.zsh.org with local id 1ox1At-000NSY-1P; Mon, 21 Nov 2022 07:25:03 +0000 Received: by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1ox1AK-000Myu-Mx; Mon, 21 Nov 2022 07:24:28 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id BAB0827C0054; Mon, 21 Nov 2022 02:24:26 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute2.internal (MEProxy); Mon, 21 Nov 2022 02:24:26 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrheehgddutdejucetufdoteggodetrfdotf 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 6571F31A0063; Mon, 21 Nov 2022 02:24:26 -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: <230a78bb-fa97-4f3a-94a2-86982316274b@app.fastmail.com> In-Reply-To: References: Date: Mon, 21 Nov 2022 02:22:38 -0500 From: =?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= To: "Bart Schaefer" , "Philippe Altherr" Cc: zsh-workers@zsh.org Subject: Re: [PATCH] Fix ERR_EXIT behavior in function calls and "always" statements Content-Type: text/plain X-Seq: 51013 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 Sun, Nov 20, 2022, at 7:43 PM, Bart Schaefer wrote: > Question for the wider list: With this patch, anonymous functions > behave like functions with respect to ERR_EXIT. This is reasonable, > but it does mean that > > set -e > { { false && true } } # does not exit > () { { false && true } } # exits > > Are we all OK with this I am not sure. On the one hand, it's consistent for anonymous functions to behave like functions here, as they do in other respects. On the other hand, this behavior violates the general idea that complex commands shouldn't cause early exits due to ignored nonzero exit statuses bubbling up from inside. While anonymous functions aren't listed as complex commands in the documentation, they certainly aren't simple commands. Function calls pop the bubbles (so to speak) because they are simple commands, not because there's anything particularly special about functions. This suggests that anonymous functions should *not* behave like normal function calls here. So yeah, I don't know. > Frankly I'm > still not certain that the extra level of { } should matter in the > function example. Does it? These seem to behave identically with Philippe's latest patches; am I overlooking something? % Src/zsh -ec '() { { false && true } }; echo done'; echo $? 1 % Src/zsh -ec '() { false && true }; echo done'; echo $? 1 -- vq