Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: param stuff and was: PATCH: 3.1.5-pws-12: _brace_parameter
- X-seq: zsh-workers 5816
- From: Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: PATCH: param stuff and was: PATCH: 3.1.5-pws-12: _brace_parameter
- Date: Mon, 15 Mar 1999 14:49:12 +0100
- In-reply-to: "Sven Wischnowsky"'s message of "Mon, 15 Mar 1999 10:46:41 NFT." <199903150946.KAA09918@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
Sven Wischnowsky wrote:
> > This wasn't working for me. The following version is. Do I really need
> > all those (@)? I was too lazy to experiment. In fact, why do I need the
> > double quotes in this case? There's no harm here in eliding empty
> > elements.
>
> In this case (and some others in the example functions) we almost
> certainly don't need the double quotes (and hence no `(@)'), this is
> just a habit of mine...
(The substitution in question was
"${(@)${(@)${(@f)$(set)}%%\=*}:gs/'//}"
to get the names of set parameters.)
The problem in this case is the $(set), which needs to be split line by
line rather than on any whitespace. If I've understood what's going on
correctly, the only way of doing that, even with the (f) flag, is in double
quotes. The (f) has an effect outside quotes, but since a $(...) there
produces the whole thing on one line, it's not what you want --- you get
everything in a single argument. I haven't found a way round.
> - makes the treatment of `${${...}...}' (hopefully) consistent (and
> this is a answer to one of Peter's questions above). The rule is:
> the inner `${...}' is broken into array elements if it yields more
> than one word and the whole thing is not quoted or if it is quoted and
> the `@' flag is used. I'd like to hear comments if you think that
> this looks and feels like the right thing.
It sounds right, although it's possible there are cases which make it more
complicated in practice.
> - allows the `${#:-foo}' Peter found. I think there is no harm in
> allowing it.
In this case, I can't see any problem, since before it was only a rather
roundabout way of getting the same as $#, as far as I can see. Maybe if
you stuck to the rules it would return the length of `foo' if $argv was
empty, otherwise $#, but that's not exactly useful. Ksh rejects this
syntax completely.
> The behavior is a bit weird, though, because `${foo-bar}' uses
> `multsub', too. I haven't changed the call to it, yet, so the result
> is that the `bar' is broken into an array -- always. This means that
> `${#:-$foo}' will yield `1' for strings and the number of elements
> if `bar' is `$baz' where `baz' is an array. I didn't change it
> because I wanted to ask what it should do first, suggestions are:
>
> 1) let it treat the `bar' always as a string (i.e. let it never be
> split into array elements); I guess this is what most people
> would expect (and in the manual the thing is called `word')
Since (without shwordsplit)
% args() { print $#; }
% args ${foo:-foo bar}
1
this is the natural thing to do.
> 2) like 1), but if combined with the `A' flag, let it be treated as
> an array
Some extension like this is reasonable, but the obvious candidate is
${(w)#:-foo bar}, which is supposed to have exactly this effect on $# for a
string.
% foo="foo bar"
% print ${(w)#foo}
2
--
Peter Stephenson <pws@xxxxxxxxxxxxxxxxx> Tel: +39 050 844536
WWW: http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy
Messages sorted by:
Reverse Date,
Date,
Thread,
Author