RPM Community Forums

Mailing List Message of <rpm-devel>

Re: Generalizing EVR comparison precedence, preliminaries

From: Jeff Johnson <n3npq@mac.com>
Date: Fri 02 Jan 2009 - 00:47:21 CET
Message-id: <D9AB8DA9-EC99-4972-8EB9-9AE151EE177E@mac.com>

On Jan 1, 2009, at 1:04 PM, Ralf S. Engelschall wrote:

>>
>> A little help vetting the RE's please ;-) My eyes are already tired
>> from writing the toy script, RE's are more effective than XML at eye
>> gouging.
>
> I propose the following three entries in "macros"...
>
>    # STEP 1: Match the string and capture regex parts
>    #                      1          2           3             4
>    #                      X     ":"  X        "-"X          ":"X
>    %evr_tuple_match  ^(?:([^:-]+):)?([^:-]+)(?:-([^:-]+))?(?::([^:-] 
> +))?$

A little more help please.

I'm using POSIX extended RE's.

With a single call to regexec(3), I'm seeing only 1 {rm_so, rm_eo}  
matched substring
returned.

What I'm expecting is what is in the toy sed script, that the tuple  
{E,V,R}
is parsed out and 4 substrings, not 1, are returned by a single  
invocation
of regexec(3), with sub-patterns that aren't matched being filled in  
somehow.

I can certainly loop over regexec(3), proceeding to match the next  
substring,
if necessary.

But I've never seen nor used RE constructs like
	^(?:......)?....$"
ever in my life.

Note also that this is the 1st time *ever* that I've programmed a  
regexec(3)
parser of this complexity in C. Not that there is anything very  
complicated in
	E:V-R
pattern matching parsing, but you know what I mean.

73 de Jeff




  • application/pkcs7-signature attachment: smime.p7s
Received on Fri Jan 2 00:47:27 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.