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 18273 invoked from network); 11 Nov 2022 04:07:36 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 11 Nov 2022 04:07:36 -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=nFXi1mJXgLEKzL5ZO4XU2OhzH0gaDjffJSy/TwL+imE=; b=CcruAamJsF+JV8GOdvmkyoiAoH a+/27LMZRy9RGfniv89jyIRR1BlhGSl1zrT6nf8lVI8ytkYqpXGZIWeHgFTFL0IDHYh9GARaj9qXD G+qK6My6MTT5iWT5/xsF7cnZsdQOX2Sc9aNA2qhVcvq+y1Fa3xEhkZ4CHfIhDiC6AQo2i6lbzIRUN IOJMxH1k65ty1dq6gVjvOBptb+sbkLjCiIbAhKIYXzcxhYjwIbxdYku//mVjq/D1n2Ddnt4gqvQP0 cFWDJMtbuxCV4ZUvynQvLQN18qeNPlW5Ea/rp/mnLNSWU1jt0loOEZ8Y78O1tCJ58myRZoYphifln htvX4ojw==; Received: by zero.zsh.org with local id 1otLKI-0005b2-So; Fri, 11 Nov 2022 04:07:34 +0000 Received: by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1otLJm-0005Gs-1a; Fri, 11 Nov 2022 04:07:02 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id CFF1427C0054; Thu, 10 Nov 2022 23:06:59 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute2.internal (MEProxy); Thu, 10 Nov 2022 23:06:59 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfeehgdeilecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreerjeenucfhrhhomhepnfgrfihr vghntggvucggvghljoiiqhhuvgiiuceolhgrrhhrhihvseiishhhrdhorhhgqeenucggtf frrghtthgvrhhnpeduudelleeiteegjedtuddtudektdeffedthedtheejgedthfduueef veelffetkeenucffohhmrghinhepmhhitghrohhsohhfthdrtghomhdpfihoohhlvggugh gvrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mheplhgrrhhrhihvodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudehud ekjeejtdegqdduudelvdejfeekhedqlhgrrhhrhihvpeepiihshhdrohhrghesfhgrshht mhgrihhlrdgtohhm X-ME-Proxy: Feedback-ID: iaa214773:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 80CE531A0064; Thu, 10 Nov 2022 23:06:59 -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: <6ddc4f89-e717-485b-aeae-e9b8fbbce2da@app.fastmail.com> In-Reply-To: References: <1edb7786-f0b2-4830-88fa-99a19bda39e2@app.fastmail.com> Date: Thu, 10 Nov 2022 23:06:39 -0500 From: =?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= To: "Philippe Altherr" , "Bart Schaefer" Cc: zsh-workers@zsh.org Subject: Re: Inconsistent behavior of ERR_EXIT with conditionals Content-Type: text/plain X-Seq: 50938 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 Thu, Nov 10, 2022, at 10:04 PM, Philippe Altherr wrote: > However, in my > experience, ERR_EXIT is often used as a safeguard for standalone > scripts. Even though it's far from perfect, it's definitely better than > nothing. Debatable. > Every now and then one of > these exceptions that you thought could/should never be thrown is > nevertheless thrown for some reason. In that case the exception goes up > the call stack and, if no catch is encountered, it kills the program > and prints a stack trace to the code that threw the exception. This way > it's obvious that something failed. It's also easy to figure out where > it happened. And, it ensures that no extra harm is done (by keeping > running the program). Only at a superficial level. https://devblogs.microsoft.com/oldnewthing/20040422-00/?p=39683 > In the world of shell scripts, there are no runtime exceptions but some > exit statuses play a similar role. Many UNIX commands and shell > functions can potentially return a non-zero exit status but when you > use them you often know (or assume) that they won't return a non-zero > exit status. Some nonzero exit statuses signify errors that should be fatal. Some don't. Some don't really indicate errors at all. ERR_EXIT makes no distinction, which is why it can cause confusion when it kills scripts overzealously. https://mywiki.wooledge.org/BashFAQ/105 > If they nevertheless do, the default behavior of shell > script is to simply ignore the error. So if "cmd1" fails in "cmd1; > cmd2", "cmd2" still gets executed. It's already bad that "cmd1" failed. > Running "cmd2" could cause extra harm. It looks much safer to exit > right after "cmd1". That's the main reason I run all my scripts with > ERR_EXIT enabled. You should handle errors properly instead of relying on ERR_EXIT to bail you out. > My impression is that ERR_EXIT is commonly used for these reasons. It is. That doesn't mean it's a good idea. > In my opinion, the only downside of that usage of ERR_EXIT is that it's > far from foolproof. Lulling script writers into a false sense of security is a pretty big downside. > There are plenty of cases where just enabling > ERR_EXIT won't be enough to ensure that the script halts at the first > unexpected error. I would like to improve that. My zabort script > already goes a long way. I do not think this idea is an improvement. I think it is more of the same false sense of security, except with rules that are somehow even more convoluted than those of ERR_EXIT. > It works around the non-propagation issues, > which are by far the main reason why just ERR_EXIT isn't enough. ERR_EXIT isn't enough because it shoehorns an error handling model into a context where it doesn't really fit. Unfortunately that ship has already sailed, but it's sailed on all shells, so at least we have company. I do not think zsh should exacerbate the situation by shoehorning even harder, and I oppose the addition of an option for doing so. -- vq