requests

requests

[Clint Adams]

For the complaint department.

Michal, how do you want ${param[(r)$anotherparam]} to behave, if not
treating $anotherparam as a pattern?

----- Forwarded message from Michal Politowski <mpol@charybda.icm.edu.pl> -----

Actually I can't tell if these are (mis)features or bugs, but I don't like
them so here comes the report.

In decreasing order of annoyance.

1. in ${param[(r)$anotherparam]} the result of $anotherparam
is always treated as a pattern, it would be nice if one could use $~anotherparam
for this.

2. ${(B)param#pattern}
gives 1 when there's no match -- could give 0 or 1+$#param like ${param[(i)pattern]}
the same for (E) and {...%...}

3. ${param[(i)pattern]} behaves differently for scalars and for arrays when
there is no match. For scalars returns 0, for arrays the index of last element + 1.

-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux Amber 2.2.19 #1 Thu Mar 29 15:52:51 CEST 2001 i586

Versions of packages zsh depends on:
ii  libc6                     2.2.2-4        GNU C Library: Shared libraries an
ii  libncurses5               5.2.20010318-1 Shared libraries for terminal hand

-- 
Michal Politowski -- mpol@lab.icm.edu.pl
Warning: this is a memetically modified message

(Fwd) Re: requests

[Bart Schaefer]

My apologies if this ends up appearing twice -- I sent it Saturday night
but it still hasn't come through the archives.

In the interim since the text below was written, I've posted a patch that
includes a fix for the #3 bug.

--- Forwarded mail from <schaefer@candle.brasslantern.com> ("Bart Schaefer")

From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
Date: Sun, 15 Apr 2001 03:28:58 +0000
To: zsh-workers@sunsite.dk
Subject: Re: requests
Cc: 92780-forwarded@bugs.debian.org, mpol@charybda.icm.edu.pl

The timing of this is interesting, as I've just spent the entire day
fooling with SourceForge bug #104052 (without making much headway).

On Apr 14,  8:24pm, Clint Adams wrote:
} Subject: requests
}
} Michal, how do you want ${param[(r)$anotherparam]} to behave, if not
} treating $anotherparam as a pattern?

He wants expansion to behave as it would outside subscript [ ]; that
is, one must use $~param to get file globbing to happen, so he'd also
like that rule to apply within subscripts.  It's fairly difficult, for
example, to match a literal "*" using subscription.

} 1. in ${param[(r)$anotherparam]} the result of $anotherparam
} is always treated as a pattern, it would be nice if one could use
} $~anotherparam for this.

The "reason" for this behavior is that the stuff inside the [ ] is,
supposedly, parsed as if double-quoted.  So in order to treat as a
pattern those strings that do NOT result from a parameter expansion,
the (r) has to imply the same sort of tokenization as $~anotherparam.

E.g. in $param[(r)foo*$bar], foo* has to first be parsed as if quoted
(otherwise it'd be a file glob!) and then tokenized, so the same happens
to $bar.

Internally, the expansion of $anotherparam is done independently of
the subscripting flag (r), which later tokenizes the fully-expanded
subscript.

One can get the desired effect by using ${param[(r)${(q)anotherparam}]},
but (another inconsistency) this works for arrays but fails for string
subscription on scalars.  That's clearly a bug.

} 2. ${(B)param#pattern}
} gives 1 when there's no match -- could give 0 or 1+$#param like
} ${param[(i)pattern]}
} the same for (E) and {...%...}

This is a known inconsistency (there's even a comment about it in the
Tests/*parameter.ztst file).  It's been left unchanged for backwards
compatibility, though it's not clear whether its use is widespread
enough that it would cause an outcry were it changed.

Probably it could be changed because nobody is using it; in fact, I'm
inclined to wonder what Michal is doing that caused him even to notice.
 
} 3. ${param[(i)pattern]} behaves differently for scalars and for arrays
} when there is no match. For scalars returns 0, for arrays the index of
} last element + 1. 

I think that one's just an implementation oversight; both forward and
reverse subscripting of scalars fall through to the same return value
when the pattern isn't found.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   


---End of forwarded mail from <schaefer@candle.brasslantern.com> ("Bart Schaefer")

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: requests

[Bart Schaefer]

On Apr 16,  4:06pm, Bart Schaefer wrote:
} Subject: (Fwd) Re: requests
}
} } 1. in ${param[(r)$anotherparam]} the result of $anotherparam
} } is always treated as a pattern, it would be nice if one could use
} } $~anotherparam for this.
} 
} One can get the desired effect by using ${param[(r)${(q)anotherparam}]},
} but (another inconsistency) this works for arrays but fails for string
} subscription on scalars.  That's clearly a bug.

I have a fix for that now, too.  It failed only when the `*' was the last
character in $anotherparam, because the code that checked for whether to
append a `*' to the pattern failed to check that the next-to-last character
might be a backslash.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: requests

[Michal Politowski]

On Sun, 15 Apr 2001 03:28:58 +0000, Bart Schaefer <schaefer@candle.brasslantern.com> wrote:
> On Apr 14,  8:24pm, Clint Adams wrote:
> } Subject: requests
> }
> } Michal, how do you want ${param[(r)$anotherparam]} to behave, if not
> } treating $anotherparam as a pattern?
> 
> He wants expansion to behave as it would outside subscript [ ]; that
> is, one must use $~param to get file globbing to happen, so he'd also
> like that rule to apply within subscripts.  It's fairly difficult, for
> example, to match a literal "*" using subscription.

Yes, that's exactly what I was expecting.

> } 1. in ${param[(r)$anotherparam]} the result of $anotherparam
> } is always treated as a pattern, it would be nice if one could use
> } $~anotherparam for this.
>
> The "reason" for this behavior is that the stuff inside the [ ] is,
> supposedly, parsed as if double-quoted.  So in order to treat as a
> pattern those strings that do NOT result from a parameter expansion,
> the (r) has to imply the same sort of tokenization as $~anotherparam.
>
> E.g. in $param[(r)foo*$bar], foo* has to first be parsed as if quoted
> (otherwise it'd be a file glob!) and then tokenized, so the same happens
> to $bar.
>
> Internally, the expansion of $anotherparam is done independently of
> the subscripting flag (r), which later tokenizes the fully-expanded
> subscript.
>
> One can get the desired effect by using ${param[(r)${(q)anotherparam}]},
> but (another inconsistency) this works for arrays but fails for string
> subscription on scalars.  That's clearly a bug.

So, do I understand correctly that changing (r) to behave as I'd like could be
rather difficult for the expected benefits (especially as there is the (q)
workaround (at least for arrays at the moment))?

Anyway I'm not desperately in need of this feature. I just noticed that
${param#foo*$bar} treating the $bar differently than ${param[(r)foo*$bar]}
is rather surprising for the casual user, independently of the lower level
reasons for this,
and I sent the report so that someday when zsh has all the possible features
someone could fix this as well.

> } 2. ${(B)param#pattern}
> } gives 1 when there's no match -- could give 0 or 1+$#param like
> } ${param[(i)pattern]}
> } the same for (E) and {...%...}
[...]
> Probably it could be changed because nobody is using it; in fact, I'm
> inclined to wonder what Michal is doing that caused him even to notice.

Actually it was nothing I personally was doing.
I was just looking for an answer to a usenet question, which was
exactly how to find if and where one variable's text is contained in another.
So for zsh (B) seemed like a simple and elegant solution, and it almost is.

-- 
Michal Politowski -- mpol@lab.icm.edu.pl
Warning: this is a memetically modified message

Re: requests

[Bart Schaefer]

On Apr 19,  5:00pm, Michal Politowski wrote:
} Subject: Re: requests
}
} So, do I understand correctly that changing (r) to behave as I'd like
} could be rather difficult for the expected benefits (especially as
} there is the (q) workaround (at least for arrays at the moment))?

Yes, you understand correctly.

And I later discovered (in the course of fixing it) that the problem with
$scalar[(r)${(q)pattern}] occurs only if $pattern ends with a `*'.

} ${param#foo*$bar} treating the $bar differently than
} ${param[(r)foo*$bar]} is rather surprising for the casual user

If that's the only thing about zsh that surprises a casual user, we're in
better shape than I thought. :-)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net