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.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, 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 CF97D254DA for ; Sun, 4 Feb 2024 02:15:00 +0100 (CET) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1707009300; b=BMjaM2pkAC2k62ozGjWkZRSDECVMyAFXhMUnmgK3GCoy5nhLxd86xK+5INGyOH4GtKuRyJrKYB 5cMkvb7O3Hy7wbElODyKyt/LtjAezYVrjZ/CbmQa5tIVx2/TrA5Ghm+cHN0b1tmFKVAR8XQIoa zQChprSm6feaOdlNcS1NK9Bu+zXsO6npwmnHQomWHXfrjWo2pTebpjWu/124kaPgle0DNF7ofd ZEUgSuJsQrS9ZidJNhWHhyLYQnE/rhCkUVQHRqdeLz04rLmKKB5Szq68iP0sK5GkgMdrTyV3d5 xtJIOhRu86RsG2soP/hCf5fYuWvmExnElF1k7ayuPT9OMQ==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mta03.eastlink.ca) smtp.remote-ip=24.224.136.9; dmarc=none header.from=eastlink.ca; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1707009300; bh=c6iLpQGEGuWvW46ZFU7/Y2g4vYhOkEv0lYo3c40uPeE=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:In-Reply-To:From:References:To:Subject:MIME-Version:Date: Message-ID:Content-Type:DKIM-Signature; b=fIQufwbpgR4d4tzzc+rW5I9ark7ctWNB8Rk9pGh1vBggC70q2x2c8rTNwZncNHqsId6dvW3uF1 t2TCPFXta8z8Q74W0POL/MLXy4OAThHQ18GROFfsw34CQJsbOSd0nSmwQnzDX1V21ZZx6WwW6T ZHL3BSwqdhPXkmuxYZm56/mBL6JrplX1c5HOV7BBrhZwIcd0Op4L/UqjYdwON1g5PNju/aABl+ J3E2NsOAvB7mHEuACzq331db37yZW6npwf4nmG4KxCdaqhy7CZVeWSCHgVk8kSbArlHvGv8Ob/ BNtlWjZaDUqgl804Pi4HwOU38eRkvXh5jEq9KDzSi90ZaA==; 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:In-reply-to:From:References:To: Subject:MIME-version:Date:Message-id:Content-type:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=KRYl2aJ0F/nEDPo/oXC/w31Szqg48/uf3DtnlxhxfAU=; b=CkstwgccQu52BnS4+Dlf3Xnn+x NO1pRzA8/0hz1q0D0s80zZR64zMMRZUoCH2BbrgXMVh/04J1hQ/ScOjQWtkNqrj/GSXj28K2a5z+i fXXd3qhFQE7BB+E4h+SKKajxRyvnz1GX2wLdZ4lCPKy2DTpfYaxQzOkNSgl0AvIAsOdVpz3H2op1m Lhlh1yKWblZBX1O58j7ubvPhvczjv0eUNOc2Vlb2QXw8erLUHWrfXIN82XNaordV5piR+VAgHfdqF iUZL/cFKD6reSeWLBSJfz5soelm2Nqn3rl75uJJOYIiFXL1moP7xtl+O+f+mYhWpvsPoDukzzJ1Bl lyAFLbbQ==; Received: by zero.zsh.org with local id 1rWR64-000Bpo-2i; Sun, 04 Feb 2024 01:15:00 +0000 Authentication-Results: zsh.org; iprev=pass (mta03.eastlink.ca) smtp.remote-ip=24.224.136.9; dmarc=none header.from=eastlink.ca; arc=none Received: from mta03.eastlink.ca ([24.224.136.9]:52329) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1rWR5R-000BA3-Ck; Sun, 04 Feb 2024 01:14:22 +0000 Received: from csp01.eastlink.ca ([71.7.199.166]) by mta03.eastlink.ca ([24.224.136.9]) with ESMTPS id <0S8B2FK4T4RGNT60@mta03.eastlink.ca> for zsh-users@zsh.org; Sat, 03 Feb 2024 21:14:20 -0400 (AST) Received: from [192.168.0.11] (host-24-207-19-13.public.eastlink.ca [24.207.19.13]) by csp01.eastlink.ca ([71.7.199.166]) with ESMTPSA id WR5PrBTnduLJ9WR5PrGy47 (version=TLSv1_2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256); Sat, 03 Feb 2024 21:14:20 -0400 X-Authority-Analysis: v=2.4 cv=PZtchThd c=1 sm=1 tr=0 ts=65bee4ec a=e7T7DzMKK1R988ZCg0wLyw==:117 a=e7T7DzMKK1R988ZCg0wLyw==:17 a=r77TgQKjGQsHNAKrUKIA:9 a=EZvFTzSLJF_-9nQMtVMA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=YwZXILmqljnvEMHd4r4A:9 a=I068BO3dwHsufTcS:21 a=_W_S_7VecoQA:10 X-Vade-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedujedgfeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecugfetuffvnffkpffmpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurheptgfkffggfgfuvfhfhfgjsegrtderredtvdejnecuhfhrohhmpeftrgihucetnhgurhgvfihsuceorhgrhigrnhgurhgvfihssegvrghsthhlihhnkhdrtggrqeenucggtffrrghtthgvrhhnpefhteethfevgeeuvdelgefgvdevudefueduffdvgfelvddvgfdtieegueeuleeifeenucfkphepvdegrddvtdejrdduledrudefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepvdegrddvtdejrdduledrudefpdhhvghloheplgduledvrdduieekrddtrdduudgnpdhmrghilhhfrhhomheprhgrhigrnhgurhgvfihssegvrghsthhlihhnkhdrtggrpdhnsggprhgtphhtthhopedvpdhrtghpthhtohepreerpdhrtghpthhtohepiihshhdquhhsvghrshesiihshhdrohhrghdpghgvthdqkghiphfrrghsshifugepthhruhgv X-Vade-Score: 0 X-Vade-State: 0 X-EL-AUTH: rayandrews@eastlink.ca Content-type: multipart/alternative; boundary="------------N01giofK036h4FmUFffjea3i" Message-id: Date: Sat, 3 Feb 2024 17:14:19 -0800 MIME-version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: for loop 'bad math expression' Content-language: en-US To: zsh-users@zsh.org 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> From: Ray Andrews In-reply-to: X-Seq: 29620 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: This is a multi-part message in MIME format. --------------N01giofK036h4FmUFffjea3i Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2024-02-03 15:52, Bart Schaefer wrote: > As Lawrence also suggested, I don't believe that happens. If a > parameter is created inside a math expression it will be assigned an > appropriate numeric type, but the type of an existing scalar is not > changed. 0 /usr/share/info 0 % var=abc; let var+=2; echo $var 2 ... it looks like the shell is simply throwing away 'abc' and starting afresh with an integer and then incrementing it. And in the manual: Note that assignment may implicitly change the attributes of a parameter. For example, assigning a number to a variable in arithmetic evaluation may change its type to integer or float, and with GLOB_ASSIGN assigning a pattern to a variable may change its type to an array. > Context-awareness doesn't extend that far. Globbing is already done > and gone by the time "for" assigns its loop variable, nothing tells > "for" where the loop values came from, and shell words on a command > line carry no type information. Sure.  I'm hardly surprised it wouldn't be practical, it was the most speculative sort of question.  And there really is no foul since my variable shouldn't have been an integer.  Actually, philosophically I'm opposed to most hand-holding anyway.  With experience I'd probably instantly detect what was going on there. But when you first bump into it, it seems inexplicable. > > You might try setopt warn_create_global to detect cases of names "leaking". > Never played with that.  Sounds useful.  As always my 'C-brain' tells me that indiscipline with variables is intolerable. --------------N01giofK036h4FmUFffjea3i Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 2024-02-03 15:52, Bart Schaefer wrote:
As Lawrence also suggested, I don't believe that happens.  If a
parameter is created inside a math expression it will be assigned an
appropriate numeric type, but the type of an existing scalar is not
changed.

0 /usr/share/info 0 % var=abc; let var+=2; echo $var

2

... it looks like the shell is simply throwing away 'abc' and starting afresh with an integer and then incrementing it. And in the manual:

Note that assignment may implicitly change the attributes of a parameter. For example, assigning a number to a variable in arithmetic evaluation may change its type to integer or float, and with GLOB_ASSIGN assigning a pattern to a variable may change its type to an array. 

Context-awareness doesn't extend that far.  Globbing is already done
and gone by the time "for" assigns its loop variable, nothing tells
"for" where the loop values came from, and shell words on a command
line carry no type information.

Sure.  I'm hardly surprised it wouldn't be practical, it was the most speculative sort of question.  And there really is no foul since my variable shouldn't have been an integer.  Actually, philosophically I'm opposed to most hand-holding anyway.  With experience I'd probably instantly detect what was going on there.  But when you first bump into it, it seems inexplicable.  


You might try setopt warn_create_global to detect cases of names "leaking".

Never played with that.  Sounds useful.  As always my 'C-brain' tells me that indiscipline with variables is intolerable.



--------------N01giofK036h4FmUFffjea3i--