From: Nikolai Weibull <mailing-lists.zsh-users@rawuncut.elitemail.org>
To: zsh-users@sunsite.dk
Subject: Re: local/typeset stupidity
Date: Mon, 20 Dec 2004 13:15:04 +0100 [thread overview]
Message-ID: <20041220121504.GB9720@puritan.pcp.ath.cx> (raw)
In-Reply-To: <200412201151.iBKBp14U018627@news01.csr.com>
* Peter Stephenson <pws@csr.com> [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);}
prev parent reply other threads:[~2004-12-20 12:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-20 11:20 Nikolai Weibull
2004-12-20 11:51 ` Peter Stephenson
2004-12-20 12:15 ` Nikolai Weibull [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041220121504.GB9720@puritan.pcp.ath.cx \
--to=mailing-lists.zsh-users@rawuncut.elitemail.org \
--cc=zsh-users@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).