[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Preventing matches in regular expressions
From: |
Jan Hudec |
Subject: |
Re: [Gnu-arch-users] Preventing matches in regular expressions |
Date: |
Tue, 10 Aug 2004 14:53:10 +0200 |
User-agent: |
Mutt/1.5.6+20040722i |
On Tue, Aug 10, 2004 at 08:47:04 -0400, Aaron Bentley wrote:
> Jan Hudec wrote:
> >>Does anyone know a better general solution?
> >
> >
> >A general solution would be to use a negative lookahead assertion. But
> >I don't know whether they are implemented in hackerlab. Hackerlab has
> >something called a "cut" operator. I can't find it's documentation so
> >I am not sure whether it can be used, but I think it can.
>
> The cut operator is documented here:
> tla-1.2/src/docs-hackerlab/html/introduction-to-regexps.html#The_cut_Operator
>
> And here:
> tla-1.2/src/docs-hackerlab/html/posix-regexps.html#Posix_Regexp_Functions
Thanks. It is not linked from documentation of the rx module and I was
not looking hard enough.
> The state label of the final DFA state for most regexps is 1 . If a
> pattern contains the cut operator [[:cut <n>:]] its DFAs will contain
> a final state with label n at that point in the regexp. This is useful
> for detecting which of several possible alternatives actually occured in
> a match, as in this example:
>
> pattern: if[[:cut 1:]]\\|while[[:cut 2:]]
>
>
> pmatch[0].final_tag is 1 after matching "if"
> pmatch[0].final_tag is 2 after matching "while"
>
> We were going to use it to optimize inventory operations by combining
> all the regexes into one. But it turned out that libhackerlab needed to
> be fixed, because the cut operator was disabling important regex
> optimizations.
I see.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec
<address@hidden>
signature.asc
Description: Digital signature