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

[Greg Klanderman <gak@xxxxxxxxxxxxxx>]

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

>> On 03 February 2021 at 15:51 Greg Klanderman <gak@xxxxxxxxxxxxxx> 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