From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19875 invoked by alias); 28 May 2015 19:42:46 -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: 35319 Received: (qmail 20203 invoked from network); 28 May 2015 19:42:45 -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=-0.3 required=5.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.0 Message-ID: <55676FB1.9080401@inlv.org> Date: Thu, 28 May 2015 21:42:41 +0200 From: Martijn Dekker User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: zsh-workers@zsh.org Subject: Arith parsing bug with minus after $# Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit After the getopts patch (which appeared within an hour after my report -- impressive!), I ran into another hurdle with the same shell function. Doing arithmetic calculations with the shell parameter containing the number of positional parameters ($#) triggers a parsing bug in arithmetic evaluation. In current zsh git code: $ zsh % set -- % echo $# 0 % echo $(($#-1)) 41 Expected output: -1, of course. Sometimes 81 is produced instead of 41! I haven't figured out a pattern yet. % echo $(($#-(1+1))) zsh: bad math expression: operator expected at `(1+1)' (expected output: -2) In both cases, it does work correctly if a space is inserted before the '-', but that space should be optional. Enabling 'emulate sh' makes no difference. This must be a long-standing bug, becasue zsh 4.3.11 that came with my Mac has it too. (According to my testing, other shells that support arith all do this correctly.) - Martijn