(Fwd) Re: requests

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx> ("Bart Schaefer")

From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 15 Apr 2001 03:28:58 +0000
To: zsh-workers@xxxxxxxxxx
Subject: Re: requests
Cc: 92780-forwarded@xxxxxxxxxxxxxxx, mpol@xxxxxxxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxxxxxxxxxx> ("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