From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from zero.zsh.org (zero.zsh.org [IPv6:2a02:898:31:0:48:4558:7a:7368]) by inbox.vuxu.org (Postfix) with ESMTP id BB83C285B9 for ; Sun, 4 Feb 2024 21:49:48 +0100 (CET) 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:To:From:Date: References:In-Reply-To:Message-Id:MIME-Version:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=c2wcSYhpMkFHVP4oeX7HknM7F8dK1T1gZWmiwkjrdqo=; b=h+T3KOvi0GRZymhk7YABEc7zXn SO+wClwVmGhEtrEfhYyQegCJ1uH2BVN/4702vFLf2ITF8awX/H5tcJT+Q/6+XaVPS/CzyQXu6Fwd4 UdqMGObGR+H2b7mQUAVUKXySwBOAB9JcDU3b3BEV5xpzNRx95KyyL2VUDt9+0E0+JuOoxk6c/qNC3 td8q3wJnPVsPV5km+/7GBYAtawnqQk5BWIm2MsGqhtNVZYSZyYhmziRIXuFW/8rbxVIlU1r7433Nc uje8lZomomEaryqHHd1PJSqEZVuSG/8yasQJzx4s9c3Igca5NIXNxbUeczkiLFguvyI/cI1jeYTY6 cRmljv8A==; Received: by zero.zsh.org with local id 1rWjQx-00037f-R1; Sun, 04 Feb 2024 20:49:47 +0000 Received: by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1rWjQH-0002QG-8m; Sun, 04 Feb 2024 20:49:05 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id 9B5EF27C0061 for ; Sun, 4 Feb 2024 15:49:03 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute2.internal (MEProxy); Sun, 04 Feb 2024 15:49:03 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedukedgudegtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreerjeenucfhrhhomhepnfgrfihrvghntggvucggvghljoiiqhhuvgiiuceolhgr rhhrhihvseiishhhrdhorhhgqeenucggtffrrghtthgvrhhnpeeileevheefgffhffeihe dtieegvdfgkeffteejgfetledtiedviedvteeukeegkeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehlrghrrhihvhdomhgvshhmthhprghuth hhphgvrhhsohhnrghlihhthidqudduhedukeejjedtgedqudduledvjeefkeehqdhlrghr rhihvheppeiishhhrdhorhhgsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Feedback-ID: iaa214773:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 60A6B31A0065; Sun, 4 Feb 2024 15:49:03 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61 MIME-Version: 1.0 Message-Id: <1745fff9-822c-499f-b60e-7248e95438c5@app.fastmail.com> In-Reply-To: References: <4c14e191-0605-4492-9f67-9a5b35ef132b@eastlink.ca> <4da0eeb4-4589-4c5d-9b89-a1a22209e18e@eastlink.ca> <7ccf5b82-a37d-47b5-a700-fb1096ab495c@eastlink.ca> <0875ffd7-e3a4-4ddc-9c4b-47e2c593ea4c@eastlink.ca> Date: Sun, 04 Feb 2024 15:48:42 -0500 From: =?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= To: zsh-users@zsh.org Subject: Re: for loop 'bad math expression' Content-Type: text/plain X-Seq: 29629 Archived-At: X-Loop: zsh-users@zsh.org Errors-To: zsh-users-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-users-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: On Sun, Feb 4, 2024, at 10:51 AM, Ray Andrews wrote: > That astonishes me. I've never heard of any such thing. Nobody > tells you these things. I'm not sure if the zsh manual spells this behavior out explicitly, but bash and ksh share it. > # abc was a string, now it's the name of an integer: These are not mutually exclusive. The value of var remains "abc" and does not change at any point. The important thing is that it is *interpreted* a certain way *in arithmetic contexts*. > % let abc+=3; print -- $((var)) > 3 This result does not correlate with the commands you've actually shown here. % var=abc % abc=1 % let abc+=3 % print -- $((var)) 4 > # var still wants to be scalar: > % var+=3; print -- $var > abc3 It doesn't "want" to be scalar, it IS scalar. But that's irrelevant. What's relevant is that it does not have the integer attribute, so "var+=3" performs string concatenation and not arithmetic incrementing. You'd see the same thing with "abc", even though it looks like a number. % abc=1 % abc+=3 % typeset -p abc typeset abc=13 (I don't know why all of a sudden you've switched from using "let" to not using it.) > # So once var has been touched directly the link to abc is broken: > % abc+=2; print -- $((var)) > 0 > > % abc=2; print -- $((var)) > 0 It's not about "touching", and there is no "link". You CHANGED its value to "abc3", and there is no such variable, so its arithmetic value is recursively taken to be zero. > ... I suppose there's a good reason for it, but that leaves me dumbfounded. If you were given these algebraic equations and asked what the value of "c" is, presumably you'd say "one" and not "the letter 'b'". a = 1 b = a c = b Same thing in shell arithmetic. % a=1 % b=a % c=b % print -- $((c)) 1 > % Sonnet_1='From_fairest_flowers_we_desire_increase'; print -- $Sonnet_1 > From_fairest_flowers_we_desire_increase There is no arithmetic context here, so you just get the raw value. > % From_fairest_flowers_we_desire_increase=1 > > % print -- $((Sonnet_1)) > 1 > > ... ok ... There *is* an arithmetic context here, so it's interpreted as an arithmetic expression. What is confusing about this? You're intentionally using unwieldy names, but the principle is the same as if you'd just used "a" and "b". > Anyway, the lesson is just not to assign a glob expansion to an > integer. The real lesson might be that you should avoid the integer attribute until you understand shell arithmetic better. -- vq