Re: trouble with question mark in regex

i managed to fix it by saying

/(#http:[^\n]*\n[^\n]*(CET|CEST) ....) and so on

that is, explicitly telling it not to capture more than a single lineshift.

On Thu, Apr 2, 2009 at 7:11 PM, Chris Babcock <[email protected]> wrote:
> On Thu, 2 Apr 2009 15:47:11 +0200
> Thomas Michael Hagen <[email protected]> wrote:
>
>> the usual behavior for ? is to make sure you capture the shortest
>> match. this does not seem to work in gerh.
>>
>> this is my code:
>>
>> match (:: :intro: :not-used: :text-chunk: :beginning-of-next-article:)
>> [:ffile:] /(#http:.*?(CET|CEST) ....)(.*?)(#http:|$)/
>>
>> i am searching through a file that contains newspaper articles
>> beginning with a header that looks something like this:
>>
>> #http://fotball.bt.no/eliteserien/article131749.ece
>> Wed Mar 11 19:08:07 CEST 2009
>>
>> i want to capture these first two lines with the variable :intro:,
>> however, at the very end of each article (in some newspapers), there
>> is a field where the journalists put their name and a timestamp. it
>> looks like this:
>>
>> S: trond
>> T: Mon Sep 25 18:14:15 CEST 2006
>>
>> the problem is that my program completely ignores the first timestamp,
>> and puts the entire article into the :intro: variable.
>
>
> I did some experimentation awhile back with right associative matching
> and I found that "(?r:expression)" was useless for my purposes - not
> because there is no use case for right associative matching, but
> because the regex library could not be relied on to default to left
> associative behavior in expressionions like /begin(.*?)marker(.*?)end/
> where "marker" occurs more than once between "begin" and "end". This
> looks like a TRE regex bug. I have no idea whether it's documented.
>
> In this case, you are trying to obtain left associative behovior and it
> just isn't happening for you. For work arounds, you can break out your
> submatch into a separate match statement or build an expression that
> includes the second time stamp explicitly. The latter approach will be
> marginally faster, but its feasibility can only be determined with your
> domain-specific knowledge.
>
> Chris
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Crm114-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/crm114-general
>
>

------------------------------------------------------------------------------