|
From: Andreas L. <av...@lo...> - 2008-11-23 10:28:28
|
On Sun, Nov 23, 2008 at 01:16:15AM +0000, Neil Madden wrote:
> I believe I proposed a "--" didn't I?
I just meant that the "--" should even then be kept, if all other
options were deferred for later (if at all)
>> [ {POSIX *} ] somehow does strike me as odd, [...as...], we
>> are *supposed* to use a string operation (pattern-matching)
>> on a list ($errorCode).
>> Perhaps this pattern should be itself taken as a list, and then
>> glob-matched element-wise (to the length of the pattern).
>
> This is exactly the purpose of -matchcommand.
But my point was, that a list-aware matching should happen by
default, such that most of the cases it works correctly, even
without implementing and installing a custom matcher.
If usage of errorCode catches on (as a hoped-for result of the
new try-command), then sooner or later someone will define
sub-types like "ARITH MATRIX" and wonder, why ARITH* doesn't
match both ARITH and "ARITH MATRIX".
It of course doesn't match the latter, because that actually
looks like "{ARITH MATRIX} ..." thus would need an optional
open brace be matched as well (How to do that with globs?)
And then it may even look like "ARITH\ MATRIX ..." sometimes,
namely if some later element of the errorCode happens to
contain an unpaired brace.
> glob as default (as [switch] already provides it),
But [switch] is not designed for list-matching.
> and leave freedom to plug in your own scheme.
My point is, that for correct programs, everyone
would not only have to specify, but even implement
his own list-matcher.
Introducing a list-string mixup directly in the core
is a very bad move, imho.
|