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,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18952 invoked from network); 9 Nov 2022 14:23:21 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 9 Nov 2022 14:23:21 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1668003801; b=Eq52Iftv/9wwI56ai3w4PyphR6HIIeT93HTrKqSmduemWUK/tQmaRdNX85lv6AX6up+OazjIYd 25KmY2Qg3iM0ei+gW1tEFmCpG7V7OlFq78bb8tZQvCWZ+KMjQlKVu/B75PTi+TlaifA0B34w0F fxQfnrCpEaJI3Uvms/ClXsrnscP5HchYhzeJtFcgTVu2AJH+USCx0wP3T7yF1KJXvZ6bN8dnS4 aV26qLK4L23KhmfspBmBppzgh3mZvt893yBw798G3kGeGoMHoaAbu83FtlRwQpRPbQnPUbk/Vo o7upvOV3XOKg8jxPJHjTcw2nys0uKx1IRYl5bvVnK2W2dg==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-vk1-f176.google.com) smtp.remote-ip=209.85.221.176; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1668003801; bh=nsmQ2BS4TRSkjBej5mp6YHUSsMlLqFnLM8MLMiOKylQ=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=ExM34R/uPFs6D7b7iItkWd7f66K/kFMtbNey27IE90kjEIk1LuLgSPGh8p/2cCjSoVwzWwLpBp BkhdMq5yB6jpMNcETaSr9OttzOFpTHsxSw/nmcyKLJhp+Ilk4c42IuDc6u14thJ+/h9biszfoX mW4MtrgIy17hMD0KGkaa0Esny1beI6/fisAHppV6N2B2UtWMwRBoCAl+bZ0fvjdk7nnArkBM4B 6Atc+DslgbNWpq5NpSnEHmuQeCbMezvhBKBDn3zxaR4cZaDESKFY5v2NMA03lhfn97qQvJ9l/I NYZBpSLvkiAHBIMoGsxcOxHM1T8KSC1smwLWY5pZVC22aw==; 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:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References: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=8lMzP4kMJCp1VbXuJNLe3NFPR8367KV7s1dWzi/8FX8=; b=OrwUQQ+rvSo1KK/JrP8deP/QAT Oy59ydMWvEXc3A3WgAO+xhcs8IkowkYbO5rZ2N/AE0/GtYH/XN2PGVJvGZT2yDZJJET9zTMWO3E2u 1WZh82yMde+VxGnZmKulNLjXhdkiC11nGGk2eRcsbTcMNDZSH93c3ovcXhpxXvNb/ICcNG6r/y8Cj d+TWFkNQVIg8Cu4cbKqbyKdUfIvjcNkx0oMOgiqFtlL1rrj24Wj/xoPUyOvGz+YQ9RcTNMC9PPpyS MD5I3nJaPS2x8tfm3CF6I/qLcwnJv7tVAb+5NwSwrt4VrIwl6vTMi1/uBNVm0LJvaNxifuHU85FeL eHzGMCTQ==; Received: by zero.zsh.org with local id 1oslz6-0003De-De; Wed, 09 Nov 2022 14:23:20 +0000 Authentication-Results: zsh.org; iprev=pass (mail-vk1-f176.google.com) smtp.remote-ip=209.85.221.176; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-vk1-f176.google.com ([209.85.221.176]:36616) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1oslyW-0002th-C5; Wed, 09 Nov 2022 14:22:45 +0000 Received: by mail-vk1-f176.google.com with SMTP id s204so11134234vkb.3 for ; Wed, 09 Nov 2022 06:22:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8lMzP4kMJCp1VbXuJNLe3NFPR8367KV7s1dWzi/8FX8=; b=UMmhY/8i5B5eXfutR4U9EysH3CVhtdVXbg1WLGQzaTaahCJbdkEfZLqG2HNEkshCnW xNYCf8RmyUd0X/iZd8q8LdHez296BRvoIbUhFDJJV3SycGFS3JWiNEQM4LBZuJ3v76We OTK6iRtxAAIdz2TCObb4tpIwfKF11bUIzBkSle/bEyDzAk3uTkDh8vy5KgZ0ZRF+YLCy yfsRl0IVhuoe+C43DiTz1kBwtkpffYsqwOt7JPrXR3XJeDh6qceayXlwRqo8Sx/zsuIw Ezfxe6+uDuUgMV6Q4bKYtJ9BJZmrCJTy2fVcU9TTwGjLgDqzP30qXflP2ngCzSyTiJpf ftsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8lMzP4kMJCp1VbXuJNLe3NFPR8367KV7s1dWzi/8FX8=; b=g6yDz3OKyl6XR05ozU8p7ZEAMvyE7EFGDKGWl4e8Ov7dlPcuxh2s2uCzu7YdPfPnQ4 vaOAslYJ27aDMvNugtKZuU6BE5P/KghIdM8CEga7yGMVqr4CyVlFI31Uxpj/IeEaIsu/ Wup1LV1FOaucjGzsIMj/MU4ZN0v38blPHog9TvONaDuei726LNyys17IICpnb8HmgD68 FhkR8bDcrlOqTtJkLId3bQczACS0upp4xB/ytDcJjEir6pnx9gTZHw8dKAt09/ovpjdV 0wL5hS2nOfuT+XYL0wGvu8IdFqf/IOJQEBzrdzO5TCKl6RzLaTvnNvCcdHyBAe0UiURP Q/TA== X-Gm-Message-State: ACrzQf02EORQi2/ubR6asd7nmkisFIOzrqTOa+5hspRtJRhbf6GHk+pG dhu17kP711zCaNxiWQuUK7t9G8opvfqV+KlFSNU= X-Google-Smtp-Source: AMsMyM6Ol2pmoGwRfnNowStr/xzUwA8kHiKMKHlLunYxBKXS4ZrsQYoBuSNBYW49fFEzYb7jGUCFyt5l47NibadF1qI= X-Received: by 2002:a05:6122:179a:b0:3b8:592d:c2a with SMTP id o26-20020a056122179a00b003b8592d0c2amr26595344vkf.7.1668003762585; Wed, 09 Nov 2022 06:22:42 -0800 (PST) MIME-Version: 1.0 References: <1edb7786-f0b2-4830-88fa-99a19bda39e2@app.fastmail.com> In-Reply-To: From: Philippe Altherr Date: Wed, 9 Nov 2022 15:22:31 +0100 Message-ID: Subject: Re: Inconsistent behavior of ERR_EXIT with conditionals To: Bart Schaefer Cc: zsh-workers@zsh.org Content-Type: multipart/alternative; boundary="000000000000c0c73705ed0a6386" X-Seq: 50925 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: --000000000000c0c73705ed0a6386 Content-Type: text/plain; charset="UTF-8" > > Neither of these is a situation where the developer should have been > relying on errexit to save them. My ultimate point with that example was to demonstrate that ERR_EXIT doesn't achieve my goal. My goal is to be able to run a Zsh script with the guarantee that if anything goes wrong the script stops immediately where by "anything goes wrong" I mean any command whose result is not otherwise checked returns a non-zero exit status. If you don't agree that this would be a useful feature, then we can stop the discussion. If you think that ERR_EXIT achieves my goal, then it would be useful if you could give me an example of a legitimate use of/reliance on ERR_EXIT. I could then try to build a better example to demonstrate that ERR_EXIT is not achieving my goal. If I fail to convince you that ERR_EXIT does not achieve my goal, then too we can stop the discussion. I would abstain from the decision and leave it to others, but I don't > believe it can be done without some rather invasive changes. Indeed, that remains an open question to me and I agree that the new option shouldn't be added if it requires too much additional complexity. Philippe On Wed, Nov 9, 2022 at 7:00 AM Bart Schaefer wrote: > On Tue, Nov 8, 2022 at 8:11 PM Philippe Altherr > wrote: > >> > >> The first developer is wrong. That's not what -e is for. A script > >> should be correct WITHOUT the use of -e ... the purpose of -e is to > >> uncover cases where the developer made a mistake, not to be an > >> integral part of the script function. > > > > I can agree with that but consider that the developer's mistake was to > use a ";" instead of an "&&" in the "backup" function. > > No, that wasn't his mistake. His mistake was to not explicitly call > "exit" on failure of scp and instead rely on errexit to bail out of > the backup function. > > The second developer's mistake was changing ; to && following the call > to the backup function without actually understanding how the backup > function (didn't) work. *If* errexit worked the way you want, the && > test would be spurious anyway, because either the function would have > returned the status of "echo" (always success) or would have died > without getting that far. > > Neither of these is a situation where the developer should have been > relying on errexit to save them. > > > My broader point was that the same error (or developer mistake) in a > function "foo" triggers an exit if "foo" is called from a plain statement > but not if it's called from within a condition. Wouldn't you agree that > it's unfortunate that the same error/mistake may or may not trigger an exit > depending on whether it's executed outside or inside a condition? > > I wouldn't necessarily agree that it's the same mistake. What's > unfortunate is that you're relying on a Deus ex machina to save your > script from disaster. > > > Would you agree to add a new shell option if it allows to run Zsh > scripts such that if any command unexpectedly fails the script immediately > stops (and its implementation doesn't require too complex changes)? > > I would abstain from the decision and leave it to others, but I don't > believe it can be done without some rather invasive changes. > --000000000000c0c73705ed0a6386 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Neither = of these is a situation where the developer should have been
relying on = errexit to save them.

My ultimate point wit= h that example was to demonstrate that ERR_EXIT doesn't achieve my goal= .

My goal is to be able to run a Zsh script=C2=A0w= ith the guarantee that if anything goes wrong the script stops immediately = where by "anything goes wrong" I mean any command whose result is= not otherwise checked returns a non-zero exit status. If you don't agr= ee that this would be a useful feature, then we can stop the discussion.

If you think that ERR_EXIT achieves my goal, then it= would be useful if you could give me an example of a legitimate use of/rel= iance on ERR_EXIT. I could then try to build a better example to demonstrat= e that ERR_EXIT is not achieving my goal. If I fail to convince you that ER= R_EXIT does not achieve my goal, then too we can stop the discussion.
=

I would ab= stain from the decision and leave it to others, but I don't
believe = it can be done without some rather invasive changes.

<= /div>
Indeed, that remains an open question to me and I agree that the = new option shouldn't be added if it requires too much additional comple= xity.

Philippe


On Wed, Nov 9, = 2022 at 7:00 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
On Tue, Nov 8, 2022 at 8:11 PM Philippe Alther= r
<philipp= e.altherr@gmail.com> wrote:
>>
>> The first developer is wrong.=C2=A0 That's not what -e is for.= =C2=A0 A script
>> should be correct WITHOUT the use of -e ... the purpose of -e is t= o
>> uncover cases where the developer made a mistake, not to be an
>> integral part of the script function.
>
> I can agree with that but consider that the developer's mistake wa= s to use a ";" instead of an "&&" in the "= backup" function.

No, that wasn't his mistake.=C2=A0 His mistake was to not explicitly ca= ll
"exit" on failure of scp and instead rely on errexit to bail out = of
the backup function.

The second developer's mistake was changing ; to && following t= he call
to the backup function without actually understanding how the backup
function (didn't) work.=C2=A0 *If* errexit worked the way you want, the= &&
test would be spurious anyway, because either the function would have
returned the status of "echo" (always success) or would have died=
without getting that far.

Neither of these is a situation where the developer should have been
relying on errexit to save them.

> My broader point was that the same error (or developer mistake) in a f= unction "foo" triggers an exit if "foo" is called from = a plain statement but not if it's called from within a condition. Would= n't you agree that it's unfortunate that the same error/mistake may= or may not trigger an exit depending on whether it's executed outside = or inside a condition?

I wouldn't necessarily agree that it's the same mistake.=C2=A0 What= 's
unfortunate is that you're relying on a Deus ex machina to save your script from disaster.

> Would you agree to add a new shell option if it allows to run Zsh scri= pts such that if any command unexpectedly fails the script immediately stop= s (and its implementation doesn't require too complex changes)?

I would abstain from the decision and leave it to others, but I don't believe it can be done without some rather invasive changes.
--000000000000c0c73705ed0a6386--