standards/52972: /bin/sh arithmetic not POSIX compliant

[Dag-ErlingSmørgrav]

The following reply was made to PR standards/52972; it has been noted by GNATS.

From: des at des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=)
To: Wartan Hachaturow <wart at tepkom.ru>
Cc: freebsd-standards at FreeBSD.org, freebsd-gnats-submit at freebsd.org
Subject: Re: standards/52972: /bin/sh arithmetic not POSIX compliant
Date: Mon, 23 Jun 2003 08:32:55 +0200

 Wartan Hachaturow <wart at tepkom.ru> writes:
 > The following reply was made to PR standards/52972; it has been noted by =
 GNATS.
 > On Sun, Jun 22, 2003 at 10:43:27PM +0200, Jens Schweikhardt wrote:
 > > The recursive processing requires that $(($a+1)) needs to undergo
 > > parameter expansion within $(()).
 >=20=20
 >  Right, but this construction works in /bin/sh:
 >=20=20
 >  wart at mojo:~$ /bin/sh
 >  $ a=3D1
 >  $ echo $(($a+1))
 >  2
 
 Yes.  It expands to $((1+1)) which evaluates to 2.
 
 >  You've said the problem was with the variable without leading $, like
 >  this:
 >  $ a=3D1
 >  $ echo $((a+1))=20
 >  arith: syntax error: "a+1"
 
 This *should* work, but doesn't.
 
 >  And, as far as my English allows me to judge, the quoted part of SUS
 >  says that "a" in this construct should be left in output as is (since it
 >  doesn't have leading $, ${, $(, etc.), shouldn't it?
 
 Yes, it should be left as-is so the part of the code that evaluates
 arithmetic expressions knows what variable is involved.  For instance,
 "$(($a+=3D1)) would expand to "$((1+=3D1))" before evaluation, which makes
 no sense, while "$((a+=3D1))" clearly says to increase a with 1.
 
 DES
 --=20
 Dag-Erling Sm=F8rgrav - des at des.no