Zsh Mailing List Archive
Messages sorted by:
Re: Parser issues and and [[ $var ]]
- X-seq: zsh-workers 32605
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: Parser issues and and [[ $var ]]
- Date: Sat, 10 May 2014 18:01:44 -0700
- In-reply-to: <140510140932.ZM32668@torch.brasslantern.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CAH_OBicpVKS-URnd-Gq=gj+qc6OhDCqf0mgDfVcda27mEEfUKg@mail.gmail.com> <140416102727.ZM19090@torch.brasslantern.com> <CAH_OBic7sX1Oc4VWn2KvX40smbRB6A7w8QGXLvPfZLD=CHMddQ@mail.gmail.com> <534FE710.firstname.lastname@example.org> <140417123722.ZM22179@torch.brasslantern.com> <email@example.com> <firstname.lastname@example.org> <CAHYJk3QOZTnicq+Nqg4BXNANa_c6_j5mhyQNK1f8YNtDhxixgA@mail.gmail.com> <email@example.com> <firstname.lastname@example.org> <email@example.com> <140426133019.ZM29630@torch.brasslantern.com> <140510140932.ZM32668@torch.brasslantern.com>
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.
Messages sorted by: