Jay Soffian <jaysoffian@xxxxxxxxx> writes:
>>> +x1="[a-z0-9]"
>>
>> Why [a-z0-9] not [0-9a-f]?
>
> No reason. It's just what popped out of my head.
>
>> I'd rather see the basic BRE grep used if you are shooting for
>> portability.
>>
>> There are some oddballs in the source (git-submodule.sh is a notable
>> offender) but none of the core-ish scripts uses egrep nor "grep -E".
>
> Sigh, I just wanted the test to pass. I did a check to see if any
> other tests were already using egrep, and when I found that they were,
> I thought that would be good enough.
>
> Originally I had switched to perl. Would you prefer:
Not really.
If we are fixing it we should do it right. The regexp you inherited seem
somewhat suboptimal, too.
"(?:PUT|MOVE) .+objects/[\da-z]{2}/[\da-z]{38}_[\da-z\-]{40} HTTP/[0-9.]+" 20\d"
- It has a double-quote. can it be anywhere or only at the beginning (if
so "^" is missing at the beginning -- I didn't check)?
- We then expect PUT or MOVE; Ok (that's "\(PUT\|MOVE\)").
- We then expect one space and one or more garbage before we see
"objects/"; do we really care if it is one-or-more garbage, or is it
zero-or-more garbage? Don't we want to see slash before "objects/" (I
think we do)?
- Then we expect objects/ and two hexdigits that should be spelled as
[0-9a-f]{2} or [0-9a-f][0-9a-f] (or $x2).
- Then we expect / and thiry-eight hexdigits, underscore and then 40
hexdigits (I think your $x38 and $x40 are fine);
- Then we expect exactly one SP followed by HTTP/ (Ok);
- And version can be one-or-more of [0-9.]; do we really allow
HTTP/..999?, or we don't care? I think we shouldn't care, and in that
case I think [.0-9]* is good enough here;
So perhaps define a variable:
good="\"\(PUT\|MOVE\) .*/objects/$x2/${x38}_$x40 HTTP/[.0-9]*" 20[0-9]\""
and grep for it?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
