From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28884 invoked by alias); 20 Jan 2016 15:00:27 -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: 37707 Received: (qmail 12574 invoked from network); 20 Jan 2016 15:00:25 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.0 Subject: Re: [PATCH] typeset: set $? on incidental error To: zsh-workers@zsh.org References: <20160114001336.GA11173@tarsus.local2> <56973114.90807@gmx.com> <20160115062645.GB12223@tarsus.local2> <20160118022557.GE3979@tarsus.local2> <20160120074752.GB29602@tarsus.local2> From: Eric Cook X-Enigmail-Draft-Status: N1110 Message-ID: <569FA0FC.3030004@gmx.com> Date: Wed, 20 Jan 2016 10:00:12 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160120074752.GB29602@tarsus.local2> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:gsYnrMvftbCvBSzjIaZx+2wy5f0zpGuaDw/zegoaurTNB3J4mmO 2gV85wiLmeCgZrZmB6YEUERwduT1v96Zsxn23rCLYZENzG76ddROvD/WvIa7sQrkjyfOljP 5k9XDyTWGchIkNJaKcEYGy6EbNgePze6oyN82u1HEkD0TXkt9IsvS0JAIvnjFKqU7o54gy6 e0+No+fQwoBAg+p5b6BFA== X-UI-Out-Filterresults: notjunk:1;V01:K0:oOI3Xrz0P7s=:t8wwcT5Fa0KqVmJmAAf3e7 VIzPYRxYzt5Lyxbth33ABtikUWDec5xDCcpWBaX6LH7jQMYJwfFQw2vkSCxEZEg3UvD1z5pvL /GMzC5zQXwl776JuL10V/gMsTSVP6nuAK+cXvNzipJ+um3mRyPv1ERFHtLRnIvbsi8Y7th6AS CvSvWVj3GRCWGCUHpA5AYUTqJ4k6yJEeubW8ORxE2LmG+XQGHotjDTZDqevX2zyQ8jgNh9GTd R3rsOZjQoRnA90RTpBrg9/0jfggky77r5Atwl6OlD09y0EQT1ZrpoUHmMp3XM4s0B7sifPI5r C9tazDdUlnoXUpuVtYaknRUFG/rIdTf6dITLJSRLDJnmQtYpLbXJw8hWm6ITtPJ3PkbxnijJa tSw4Bx7bYGMhA4dt6K4aWymhurXGukzAtVVzcWAuoj18qlSfutEkEMP/TMz72CjeVE/7vCgAE tCbOUw3hWv5INyaHHim0oQlt8n7FwJ6hfmmus9MZdmotq5WRjfBb7gjHgwrvd90WIGEWhPYsf q9QKH0O/2oj0l/UVQVkAPEK8RLvxQqBdU78yrvWIQwJxJv6T1X0sCgKjFB5Yk4fhkZ5G+Pu0o wM0Kf4Zauj4ltBuPWINWUrOq1cBBoCZiDeQsDlWr4leQ6osp74UgBJHl6p8YiOPetWvS2X1xZ z32x1bZgAuST6xewXiDs+CLZhUmJfJWZlcfP15KK6RDXMTrGhh8m/WZyW0F84Qga5FHTlP6JV EQHFI9orpqdZaeBMyEivIYCIsEKzlTvNSszDRaG7+xGvY5s3SRN/52XF6ttn/+72aWAZv5dlJ 1Y9KQFD On 01/20/2016 02:47 AM, Daniel Shahaf wrote: > Mikael Magnusson wrote on Mon, Jan 18, 2016 at 05:38:17 +0100: >> On Mon, Jan 18, 2016 at 3:25 AM, Daniel Shahaf wrote: >>> Mikael Magnusson wrote on Fri, Jan 15, 2016 at 15:46:09 +0100: >>>> On Fri, Jan 15, 2016 at 7:26 AM, Daniel Shahaf wrote: >>>>> Eric Cook wrote on Thu, Jan 14, 2016 at 00:24:36 -0500: >>>>>> On 01/13/2016 07:13 PM, Daniel Shahaf wrote: >>>>>>> The 'typeset' family of builtins doesn't set $? when one would expect it >>>>>>> to do so: >>>>>>> >>>>>>> % x=$(true) y=$(exit 42); echo $? >>>>>>> 42 >>>>>>> % local x=$(true) y=$(exit 42); echo $? >>>>>>> 0 >>>>>>> >>>>>>> This patch makes 'typeset' behave as ordiary assignment does. >>>>>> >>>>>> >>>>>> But who expects that? >>>>> >>>>> I did. >>>> >>>> local/typeset is a command, and it was successful, so I don't see why >>>> $? should be set to anything else than 0. >>>> % true x=$(false); echo $? >>>> 0 >>>> is technically exactly the same situation as your above second command. >>> >>> I wouldn't call it successful: I asked for the parameter x to be created >>> as a scalar and assigned a value and only part of my request was >>> accomplished. >> >> That's not true, the parameter is created and assigned the value you >> asked for (your command subst had empty output so the parameter is "" >> but if you did local y=$(echo hi; exit 42) it would be "hi".) > > In real-life examples, if the command subst had a non-zero exit status, > the value would typically _not_ be the one I asked for: > > % cd $(mktemp -d) > % local mtime=$(zstat +mtime myfile) > zstat: myfile: no such file or directory > % echo ${(q)mtime} $? > '' 1 > But local is still the last command to run and local successfully created the parameter mtime. The commands that may possibly execute during the parsing of the line, affecting the actual command's exit status is a weird side effect that doesn't happen elsewhere. The change is only useful if mtime is the last argument for local. x=$(exit 42) y=$(true); echo $? 0 So in the event that you actually care about the exit status of a command during assignment, explicitly testing a normal assignment after making the parameter local makes sense. local mtime if mtime=$(zstat +mtime myfile); then ... The last command to run in the conditional is actually zstat, so $? changing is logically there.