Re: zsh -n does not detect incorrect associative array declaration

[Paul Wayper <paulway@xxxxxxxxxx>]

On 23/03/16 17:40, Bart Schaefer wrote:
> On Tue, Mar 22, 2016 at 7:28 PM, Paul Wayper <paulway@xxxxxxxxxx> wrote:
>> On 23/03/16 11:20, Bart Schaefer wrote:
>>> Technically, the shell is ALSO prohibited by NO_EXEC from executing
>>> the "typeset" command, and therefore can't possibly know that "fn"
>>> represents an associative array in the first place.
>>>
>>> The NO_EXEC option is only useful for the most rudimentary of syntax
>>> checks.  It cannot detect/predict execution-time inaccuracies.
>> Given that situation, should we update the zsh manual to point out that
>> the -n option cannot check the syntax of commands that are evaluated, so
>> that this is more explicit?  I'd be happy to write such an update and
>> push it if you'd prefer that.
> I don't have a preference here, but I don't think there's any reason
> for the zsh manual to be any more explicit than the manual for any
> other shell; for example bash:
>
>      -n      Read commands but do not execute them.  This may be used
>              to check a shell script  for  syntax  errors.   This  is
>              ignored by interactive shells.

I guess I would change that to read:

"Read commands but do not execute them.  This may be used to check a
shell script for most syntax errors, but cannot check inside evals and
other invocations."

> There's nothing *syntactically* wrong with
>
> fn=(foo_key foo_val bar_key)
>
> Even when executing commands normally, the syntax analyzer does not
> know that the assignment will fail if there are an odd number of
> values in the list.  That's a semantic error discoverable only when
> the assignment is performed.  The shell language is interpreted, not
> truly compiled, so parameter type information is not used in syntax
> analysis.  Plus, you're still ignoring the fact that the shell doesn't
> know "fn" is associative because it was not allowed to interpret the
> foregoing "typeset" command.

I see what you mean.  I would have expected the syntax check depended on
the typeset command, enough that it allows it to execute or stores the
type of the declared variable.  But as you say this is an interpreted
language so typed variables are somewhat bolted-on.

Anyway, I understand the situation now, so I can solve my problem.

Thanks once again,

Paul

-- 
Paul Wayper -- Senior Software Maintenance Engineer -- RHCE
Red Hat -- Australia -- Canberra