--- In [email protected], "Sheri" <sheri...@...> wrote: > > For example, the pattern > > X(*MARK:A)Y|X(*MARK:B)Z > > after matching against XY, the markstring would be "A". > Other verbs could also set the string. E.g., (*PRUNE:A) would be equivalent > to (*MARK:A)(*PRUNE). (*THEN:A) would be the same as (*MARK:A)(*THEN).
Can't say I follow that bit, but never mind. Is it possible to need or get more than one markstring per match? I would guess not, from what you quote re api and pcre test, but I don't understand why not. Never mind. Assuming only one markstring can happen as a result of call to plugin pcreMatch, could plonk it in a new standard variable, e.g. regex_mark. I assume markstrings would be ignored in pcreMatchall, pcrerReplace > I guess the point is, after the match, it could be possible to do some > conditional processing dependent on the content of the markstring. I suppose > some new regex plugin option might be needed to communicate that when you > want a markstring. ? Appears the pcretest.exe app in the test version has an > option to retrieve the markstring. > > From the draft pcreapi doc: > > If PCRE_EXTRA_MARK is set in the flags field, the mark field must be set to > point to a char * variable. If the pattern contains any backtracking control > verbs such as (*MARK:NAME), and the execution ends up with a name to pass > back, a pointer to the name string (zero terminated) is placed in the > variable pointed to by the mark field. The names are within the compiled > pattern; if you wish to retain such a name you must copy it before freeing > the memory of a compiled pattern. If there is no name to pass back, the > variable pointed to by the mark field set to NULL. For details of the > backtracking control verbs, see the section entitled "Backtracking control" > in the pcrepattern documentation. > > Regards, > Sheri >
