zsh-users
 help / color / mirror / code / Atom feed
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);}


      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).