Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: zsh -n and modules
- X-seq: zsh-workers 18055
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: zsh -n and modules
- Date: Sun, 5 Jan 2003 22:35:31 +0000
- Cc: 175467@xxxxxxxxxxxxxxx
- In-reply-to: <20030105201312.GA2058@xxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20030105201312.GA2058@xxxxxxxx>
On Jan 5, 3:13pm, Clint Adams wrote:
}
} If you run zsh -n on a script which uses zsh/mathfunc, zsh will
} not exec zmodload, and thus not be aware of new math syntax.
} Is an EXEC_ZMODLOAD option in order?
That solution is not particularly useful. Consider something of the form
if test ...
then zmodload zsh/mathfunc
fi
If you can't execute the conditional because of -n, how do you know that
it's safe to execute the zmodload?
IMO you've identified a deeper problem, which is that no module should be
allowed to alter the syntax accepted by the parser. Conversely, if the
parser is able to cope with the syntax in the absence of the module, then
`zsh -n' has no business complaining about the semantics.
In this example:
> /usr/bin/vux:766: unknown function: int
`zsh -n' should simply accept that `int' IS a function, and should not try
to look it up.
In this case:
> /usr/bin/vux:784: bad math expression: operator expected at `h'
I can't give an opinion, "bad math expression" is too generic an error.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
Messages sorted by:
Reverse Date,
Date,
Thread,
Author