zsh-workers
 help / color / mirror / code / Atom feed
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


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