From: Peter Stephenson <pws@ibmth.df.unipi.it>
To: zsh-workers@sunsite.auc.dk
Subject: Re: assoc array assignment problem.
Date: Tue, 28 Sep 1999 14:15:43 +0200 [thread overview]
Message-ID: <9909281215.AA16286@ibmth.df.unipi.it> (raw)
In-Reply-To: ""Bart Schaefer""'s message of "Tue, 21 Sep 1999 04:59:34 DFT." <990921045934.ZM13380@candle.brasslantern.com>
"Bart Schaefer" wrote:
> } Hm. Variable expansion is performed twice.
>
> This is not an associative array problem; it affects all arrays. Note:
>
> zagzig<17> q=()
> zagzig<18> g=7
> zagzig<19> f='$g'
> zagzig<20> q[$f]=seven
> zagzig<21> print $#q $q
> 7 seven
> zagzig<22>
>
> The first substitution happens at the expected time, during evaluation
> of the line. The second one happens at execute time in addvars() --
> assignment is implemented as if `x=y somecommand` where somecommand is
> null.
Two comments:
- addvars() is performing an initial substitution on the LHS, but the
parameter expansion code isn't; with $q[$f], nothing gets substituted
until the look up for q[$f] on hitting the first `$'. I don't
see why addvars() needs to do that initial substitution, though:
in the old days, you could do `foo=bar; $foo=something' to set bar,
but now you can't. So I suspect that first substitution may be redundant,
and that all substitution should be delayed until the parameter code,
as it is when a parameter is being used rather than asssigned.
However, this does untokenize the name, which maybe partly explains the
following behaviour.
- The weirdest thing seems to me to be that getindex() is untokenizing
the [...] part, only for it to be retokenized again down in getarg().
This can't be right, can it? It would be far better if what getindex()
gets is correctly tokenized according to whether or not you want it
substituted (including not untokenizing it in addvars()), and if that was
respected this problem would go away. That should be OK, because
the subscript should already be tokenized in just the same way
as the parameter expansion. Shouldn't it?
- (three comments, among the comments are): Looking at addvars(),
it seems that the following (with no existing $foo):
setopt restricted
foo=bar cat /dev/null
could be bad for business, but AIX is unable even to give me the
satisfaction of a core dump.
I get fed up with this shell sometimes. Maybe I'll take a look at this,
but I'd prefer to retreat into a hole in the ground.
--
Peter Stephenson <pws@ibmth.df.unipi.it> Tel: +39 050 844536
WWW: http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy
next prev parent reply other threads:[~1999-09-28 12:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-09-21 1:37 Tanaka Akira
1999-09-21 4:59 ` Bart Schaefer
1999-09-28 12:15 ` Peter Stephenson [this message]
1999-09-28 13:04 ` Peter Stephenson
1999-09-30 16:58 ` Bart Schaefer
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=9909281215.AA16286@ibmth.df.unipi.it \
--to=pws@ibmth.df.unipi.it \
--cc=zsh-workers@sunsite.auc.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).