Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: local/typeset stupidity
- X-seq: zsh-users 8305
- From: Nikolai Weibull <mailing-lists.zsh-users@xxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-users@xxxxxxxxxx
- Subject: Re: local/typeset stupidity
- Date: Mon, 20 Dec 2004 13:15:04 +0100
- In-reply-to: <200412201151.iBKBp14U018627@xxxxxxxxxxxxxx>
- Mail-followup-to: zsh-users@xxxxxxxxxx
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <20041220112025.GA9720@xxxxxxxxxxxxxxxxxx> <200412201151.iBKBp14U018627@xxxxxxxxxxxxxx>
* Peter Stephenson <pws@xxxxxxx> [Dec 20, 2004 13:00]:
> > func () { local s="..." }
> >
> > then I don't expect zsh to respond with
> >
> > func:local:1: not valid in this context: 100
> >
> > right?
> There's something you're not telling us. With the default zsh options
> the syntax you show is guaranteed to work. My guess is something is
> causing what you show in "..." to be split into words. Is there a
> "$@" inside it? For example,
> func() { local s="$@" } func foo 100
Argh, man, I need to get used to hom $(...) works. It looks like one
element, but its of course split in that position.
> s="..."
> is special syntax; it's recognised as a scalar assignment, so
> wordsplitting is implicitly turned off. This differs from "local"
> which has the semantics of a normal builtin, almost (actually, there's
> special behaviour of ~'s and ='s at the start of the value).
> This is rather nasty. People often expect assignments after "local"
> etc. to be the same as assignments on their own, but that syntax
> conflicts with the way the arguments of builtins, and any other
> commands, are handled. There's no simple answer, but retaining
> builtin syntax is at least predictable and stops the already
> horrendous code for local variables from becoming any worse. Any way
> round is a kludge of some sort.
This is what fooled me, yes.
> > Even with
> >
> > setopt typesetsilent # (how can't this be the default?)
> typesetsilent works around a different problem:
> func() { local s; local s; } func
> outputs
> s=''
> unless the option is turned on. This came from the very early days of
> zsh. It was mostly useful for examining the state of variables that
> already exist interactively; it's not obvious you would use it in a
> function. It's annoying this is the default behaviour. There may be
> a better way of suppressing the output in functions, but I'm not sure
> whose functions it would break. Personally I'd be quite happy to have
> the effect of typesetsilent enforced inside functions. A compromise
> would be to keep the non-silent behaviour only for "typeset" itself.
Yes, definitely. It's weird where the language has dynamic binding, yet
"complains" about things like this.
Thanks for your help,
nikolai
--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
Messages sorted by:
Reverse Date,
Date,
Thread,
Author