Reply to message «zsh -n doesn't grok associate array indexes?», 
sent 20:18:09 10 January 2011, Monday
by Rocky Bernstein:

Confirmed:
    zsh << EOF
    emulate -LR zsh
    typeset -A hash
    hash['display']=5
    echo ${hash['display']}
    EOF
echoes 5 as expected, but «zsh -n» echoes the same error.

    % zsh --version
    zsh 4.3.10 (x86_64-pc-linux-gnu)

By the way, if I replace «'display'» with «display» (which is correct because 
zsh does not unquote subscripts, you can check it by using «echo ${(kv)hash}») I 
I get correct value without «-n» and «zsh: hash: assignment to invalid subscript 
range» with «-n».

By the way, I can't find description of «NO_EXEC» option in «man zshoptions».

Original message:
> I tried zsh -n to see how good a tool it might be for lint checking.
> Overall it works very well.
> 
> However I ran into a problem when using a string associative array index.
> Here's a sample run:
> 
> $ cat /tmp/zsh-bug.sh
> 
> > typeset -A hash
> > hash['display']=5
> > echo ${hash['display']}
> > $ zsh /tmp/zsh-bug.sh
> > 5
> > $ zsh -n /tmp/zsh-bug.sh
> > /tmp/zsh-bug.sh:2: bad math expression: operand expected at `'display''
> > /tmp/zsh-bug.sh:3: bad math expression: operand expected at `'display''
> > $ zsh --version
> > zsh 4.3.10 (i686-pc-linux-gnu)
> > $
> 
> By the way, I also tried ksh -n from version 93u- 2010-09-22. It also
> catches basic syntax errors such as with
> complex statements (if, while, case, for) but offers a number of lint- like
> suggestions such as to improve speed and and allow for better
> ksh conformance. Out of 57 or so files I tried in the zshdb
> distribution, there were about 5 errors which I don't think anythingn could
> be done about, i.e. legitimate differences between zsh and ksh. However
> there were many  warnings for performance improvements, removing deprecated
> constructs and better ksh conformance.