From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20174 invoked from network); 15 May 2000 18:21:19 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 May 2000 18:21:19 -0000 Received: (qmail 10261 invoked by alias); 15 May 2000 18:21:13 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11386 Received: (qmail 10254 invoked from network); 15 May 2000 18:21:12 -0000 Date: Mon, 15 May 2000 19:20:44 +0100 From: Peter Stephenson Subject: Re: PATCH: octal in arithmetic expressions In-reply-to: "Your message of Mon, 15 May 2000 13:51:09 EDT." <20000515135109.A31551@scowler.net> To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Message-id: <0FUM00JQE5MJSH@la-la.cambridgesiliconradio.com> Content-transfer-encoding: 7BIT > This should make zsh conform to POSIX in this regard. i.e. $(( 010 )) is treated as 8. We had this, but removed it because it messed up huge numbers of shell scripts (including mine) with perfectly reasonable leading zeroes that never did anyone any harm, and very few people needed octal, and there are other, less ambiguous ways of specifying it. Consider for example, % print -P %D 00-05-15 If you extract bits of this as a string and then try to do math on it, it falls other if the number is 08 or 09. This is much more the sort of thing most zsh users are likely to want to do rather than parsing octal. It should be settable with some option such as MATH_MODE_MESSES_UP_CONVERSIONS_FROM_STRING_TO_INTEGER... well, all right, OCTAL_ZEROES. As ksh doesn't do this it probably shouldn't be set for ksh emulation. Unfortunately there isn't a specific posix emulation mode; there probably should be. I suppose it would be OK to set it in sh emulation, since only sh's trying to be posix-like would have math evaluation. -- Peter Stephenson Cambridge Silicon Radio, Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070