From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25408 invoked by alias); 11 May 2014 01:01: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: 32605 Received: (qmail 23640 invoked from network); 11 May 2014 01:01:40 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <140510180144.ZM26488@torch.brasslantern.com> Date: Sat, 10 May 2014 18:01:44 -0700 In-reply-to: <140510140932.ZM32668@torch.brasslantern.com> Comments: In reply to Bart Schaefer "Re: Parser issues and and [[ $var ]]" (May 10, 2:09pm) References: <140416102727.ZM19090@torch.brasslantern.com> <534FE710.3020601@eastlink.ca> <140417123722.ZM22179@torch.brasslantern.com> <20140423165024.1480528a@pws-pc.ntlworld.com> <20140425172112.7bf50606@pwslap01u.europe.root.pri> <140426133019.ZM29630@torch.brasslantern.com> <140510140932.ZM32668@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Parser issues and and [[ $var ]] MIME-version: 1.0 Content-type: text/plain; charset=us-ascii I've found a couple of other bugs with 32604, so it's probably just as well that I didn't commit/push it. Does anyone know why the lexer sometimes sets (tok = DOUTBRACK, tokstr = "\220\220") and other times (tok = DOUTBRACK, tokstr = NULL) ? It would seem as though it ought to be consistent. It does seem to consistently "return" (tok = DAMPER, tokstr = NULL) for example. On May 10, 2:09pm, Bart Schaefer wrote: } } [ -t ] >/dev/null } } is true in bash3.2 but false in ksh93 (including builtin test). As far } as I can tell, this is the only operator that behaves this way, both } bash and ksh treat all other binary operators as strings when they } have no argument. Of course I meant to write "prefix operators" not "binary". } I think the following produces syntax errors in all the places it should } and works in the rest of the cases, but I have not yet tested it with } new conditionals added by modules -- e.g., the recomputation of dble } for s2 (last hunk) may need knowledge of added conditions. With the patch from 32604 in place, I added a simple prefix operator to the example module: CONDDEF("m", 0, cond_p_m, 0, -1, 0), This should accept any number of arguments including none. I created cond_p_m() to return 0 if there are no arguments and 1 if there are any arguments (recall that the C function return values are inverted from the shell true/false return status). After recompiling and loading zsh/example, [[ -m ]] returns true. GDB confirms that cond_p_m() is never being called. The condition callback is correctly invoked for [[ -m 1 2 ]] etc. On the other hand, WITHOUT 32604, [[ -m ]] is a parse error, so it would appear that prefix operators are not allowed to have no arguments. This should probably be documented. Back on the first hand, in ksh93 [[ -z ]] is a parse error (that is, a prefix operator is never tested as a plain string except in "test") whereas [[ -m ]] is not (because there is no -m operator). So it would seem that once an operator is defined, it should not be allowed to parse as a string. Thus it would seem that the parser does need a way to explicitly test for module-defined operators to also support non-operator non-empty strings evaluating as true. Or, we can decree that any string that starts with a "-" is treated as an operator, since all module-defined operators must start with "-", which would differ from ksh93 but not from previous zsh. (foo=-m; [[ $foo ]]) would still test as a string.