Re: Parser issues and and [[ $var ]]

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Sat, 10 May 2014 18:01:44 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> 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 must surely be an oversight.  I think a long time ago the lexer
didn't bother setting tokstr when there was a unique token, since the string could in principle be deduced; however, it proverd much more convenient just to be
able to use tokstr in any case.  So it probably hasn't been updated properly.
 
> 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.

I think the latter is probably acceptable, but maybe there should be an
interface saying a condition code defined by a module has been called with
zero arguments (which might on failure alternatively confirm that there
was no such condition code, allowing a different interpretation).

pws