From: "Bart Schaefer" <schaefer@brasslantern.com>
To: zsh-workers@sunsite.auc.dk
Subject: Re: BUG: zsh-3.1.5-pws-14: parameter expansion not working properly
Date: Sun, 9 May 1999 10:49:40 -0700 [thread overview]
Message-ID: <990509104940.ZM21070@candle.brasslantern.com> (raw)
In-Reply-To: <9905071151.AA42253@ibmth.df.unipi.it>
In-Reply-To: <199905071336.PAA12641@beta.informatik.hu-berlin.de>
On May 7, 1:51pm, Peter Stephenson wrote:
} Subject: Re: BUG: zsh-3.1.5-pws-14: parameter expansion not working proper
}
} Sven Wischnowsky wrote:
} >
} > [ There is a little patchlet below. I don't suggest using it to
} > everyone just now, it's just that I can think about this better when
} > I have cod to play with. Didn't have the time for this yesterday. ]
}
} Is there any agreement on this patch (6046) to introduce the variable
} mult_isarr to keep track of whether a nested parameter substitution returns
} an array?
I think it's more sensible behavior than what's happening now. It's a
little less likely to break scripts written for 3.0.x, too.
} If so, what documentation changes are needed (which might help
} tell everyone else what it's doing)?
We'd have to revise the "parameter expansion rules" section that you
added. In particular, the latter part of this:
1. *Nested Substitution*
If multiple nested `${...}' forms are present, substitution is
performed from the inside outwards. At each level, the
substitution takes account of whether the current value is a
scalar or an array, whether the whole substitution is in double
quotes, and what flags are supplied to the current level of
substitution; the flags are not propagated up to enclosing
substitutions. The value passed back to an enclosing substitution
is always an array, which however will consist of one word if the
value was not itself an array. All the following steps take place
where applicable at all levels of substitution.
Becomes (see Sven's note):
... the current level of
substitution, just as if the nested substitution were the
outermost. The flags are not propagated up to enclosing
substitutions; nor are arrays joined into strings, nor strings
split into arrays, except as indicated by the flags at the
current level as adjusted for quoting. All the following steps
take place where applicable at all levels of substitution.
I don't know whether we'd want to add something like:
Note that, unless the (P) flag is present, the flags and any
subscripts at each enclosing substitution apply directly to the
value of the nested substitution.
Then as Sven mentioned:
2. *Parameter Subscripting*
If the value is a raw parameter reference with a subscript, such
as ${VAR[3]}, the effect of subscripting is applied directly to
the value of the parameter. Subscripts are evaluated left to
right; each second and succeeding subscript applies to the value
yielded by the previous subscript. Thus, if VAR is an array,
${VAR[1][2]} is the second character of the first word, but
${VAR[2,4][2]} is the entire third word (the second word of the
range of words two through four of the original array).
Perhaps an example should note that
${foo[2,4][2]} == ${${foo[2,4]}[2]} (No quotes!)
${${foo[2,4]}[2]} != "${${foo[2,4]}[2]}" (Quotes matter)
${${foo[2,4]}[2]} == "${${(@)foo[2,4]}[2]}" ((@) matters)
And finally, the example changes Sven described.
} And what about the other glitch that was noticed, that a single word
} array is always turned into a scalar (currently around line 1471 in
} subst.c), do we get rid of that for consistency?
I tried deleting that and got a core dump elsewhere in subst.c. There's
a loop over the array that assumes index 1 must not be null because it's
not possible (when the line-1471-code is present) to get there with a 1-
element array. I haven't worked out whether there are other consequences
to stopping that loop sooner.
I think we should correct it, but there's almost certainly some reason
for it, perhaps now lost in the mists of time.
On May 7, 3:36pm, Sven Wischnowsky wrote:
} Subject: Re: BUG: zsh-3.1.5-pws-14: parameter expansion not working proper
}
} About changes needed in the shell code: I once had this patch in my
} version, of course. I used as a normal working shell and the
} completion functions at least didn't suffer from it. But they (almost?)
} always use the `(@)' flag on every level and the behavior for that
} wasn't changed. I haven't tried all example shell code stuff we have,
} but a quick `grep @ ...' looks good (we don't use subscripts on nested
} parameter expansion very often, it seems).
Right.
The only good alternatives at this point are probably [a] go back to the
3.0 behavior of (@), or [b] leave it the way this mult_isarr patch leaves
it. Can anyone think of something in between that makes sense?
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
next prev parent reply other threads:[~1999-05-09 17:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-04-16 7:36 Sven Wischnowsky
1999-04-16 7:48 ` Andrej Borsenkow
1999-04-16 9:04 ` Bart Schaefer
1999-04-16 9:26 ` Andrej Borsenkow
1999-04-18 23:39 ` Bart Schaefer
1999-05-07 11:51 ` Peter Stephenson
1999-05-07 13:36 ` Sven Wischnowsky
1999-05-09 17:49 ` Bart Schaefer [this message]
1999-05-10 8:28 ` PATCH: mult_isarr documentation Peter Stephenson
-- strict thread matches above, loose matches on Subject: below --
1999-05-10 9:13 BUG: zsh-3.1.5-pws-14: parameter expansion not working properly Sven Wischnowsky
1999-04-15 12:08 Sven Wischnowsky
1999-04-15 20:10 ` Bart Schaefer
1999-04-15 6:49 Sven Wischnowsky
1999-04-15 11:03 ` Bart Schaefer
1999-04-12 7:17 Sven Wischnowsky
1999-04-14 17:27 ` Bart Schaefer
1999-04-10 11:28 Geoff Wing
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=990509104940.ZM21070@candle.brasslantern.com \
--to=schaefer@brasslantern.com \
--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).