pattern matching, when the pattern is a parameter expansion

pattern matching, when the pattern is a parameter expansion

[Greg Klanderman]

Hi,

I seem to have found an inconsistency with pattern matching,
when the pattern is a parameter expansion:

% z=(one two three)

in three syntactic forms that accept a pattern, the pattern can be the
result of a parameter expansion:

% x=two
% [[ two == $x ]] && echo yes || echo no
yes
% echo "${(@)z:#$x}"
one three
% echo "${z[(i)$x]}"
2

now, when x contains an actual pattern rather than a simple string, it
is not matched in the first two cases, but is in the final case:

% x='t*'
% [[ two == $x ]] && echo yes || echo no
no
% echo "${(@)z:#$x}"
one two three
% echo "${z[(i)$x]}"
2

I would have actually expected to match in the first two cases as
well; is this behavior of using plain string matching when the pattern
is a parameter expected documented?

(I know I can get that behavior with the 'e' subscript flag in the
final case)

There is some explanation of pattern matching in Chapter 12
(Conditional Expressions) which seems relevant but not clear on these
cases:

| Normal shell expansion is performed on the file, string and pattern
| arguments, but the result of each expansion is constrained to be a
| single word, similar to the effect of double quotes.
..
| Pattern metacharacters are active for the pattern arguments; the
| patterns are the same as those used for filename generation, see
| Section 14.8 [Filename Generation], page 73, but there is no special
| behaviour of ?/? nor initial dots, and no glob qualifiers are allowed.


thank you,
Greg

Re: pattern matching, when the pattern is a parameter expansion

[Peter Stephenson]

> On 03 February 2021 at 15:51 Greg Klanderman <gak@klanderman.net> wrote:
> % x='t*'
> % [[ two == $x ]] && echo yes || echo no
> no
> % echo "${(@)z:#$x}"
> one two three
> % echo "${z[(i)$x]}"
> 2
> 
> I would have actually expected to match in the first two cases as
> well; is this behavior of using plain string matching when the pattern
> is a parameter expected documented?

To cut a long story short: the third case is actually the odd one out.
Subscripts always treat the argument as a pattern --- the basic doc
for that is the under the "r" subscript flag, to which "i" refers.
(I find this somewhat inconvenient as it makes subscript arguments
hard to quote.)

Otherwise, substituted pattern characters are not active by default:
see the GLOB_SUBST option.  You can turn this on with a "~" after
the "$", see the description of ${~spec} in the zshexpn manual.

% x='t*'
% [[ two == $~x ]] && echo yes || echo no
yes

pws

Re: pattern matching, when the pattern is a parameter expansion

[Greg Klanderman]

>>>>> On February 3, 2021 Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:

>> On 03 February 2021 at 15:51 Greg Klanderman <gak@klanderman.net> wrote:
>> % x='t*'
>> % [[ two == $x ]] && echo yes || echo no
>> no
>> % echo "${(@)z:#$x}"
>> one two three
>> % echo "${z[(i)$x]}"
>> 2
>> 
>> I would have actually expected to match in the first two cases as
>> well; is this behavior of using plain string matching when the pattern
>> is a parameter expected documented?

> To cut a long story short: the third case is actually the odd one out.
> Subscripts always treat the argument as a pattern --- the basic doc
> for that is the under the "r" subscript flag, to which "i" refers.

Ahh now I see it.. I had read the doc under 'r' and 'i', but the note
which describes this is under 'R', and I didn't continue reading that
one after the first sentence "Like 'r'  but gives the last match".  I
should know after ~25 years to read everything anywhere nearby for all
the additional nuggets...

> (I find this somewhat inconvenient as it makes subscript arguments
> hard to quote.)

But you can just use the 'e' flag, right?

> Otherwise, substituted pattern characters are not active by default:
> see the GLOB_SUBST option.  You can turn this on with a "~" after
> the "$", see the description of ${~spec} in the zshexpn manual.

Thanks for pointing that out.. another hidden nugget!

I wouldn't have guessed the globbing option would turn that on,
but of course it makes sense once you know..

I just found 'jobs -Z' yesterday; never in a million years would I
have guessed that functionality would be associated with 'jobs' but
found it reading the source code to determine how hard it would be
to add just such a feature!

Greg