Re: ListMatch Clarification

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 05:06 AM 6/23/2004, Daniel Henninger wrote:
>=)  Ok, I hushed up briefly to let all the responses come in and level
>off.  So one important thing I am to understand is that * is not
>'wildcard', instead it means:
>
>Foo*      Foo is at the beginning of the line

Foo is to be matched with initial portion of the value,
in this case, the beginning of the first line of the list.

>*Foo      Foo is at the end of the line

Foo is to be matched with final portion of the value,
in this case, the end of the last line of the list.

>*Foo*     Foo is somewhere in the line

Foo is to be matched with a portion of the value,
in this case, any part of any line of the list.

>I am still not clear on *Foo*Raleigh*.  Is that equal to:
>*Foo*
> and
>*Raleigh*

No, the substrings assertion *Foo*Raleigh* is not
equivalent to the AND of substrings assertions *Foo*
and *Raleigh*.

In evaluation of *Foo*Raleigh*, Foo is to matched with any
part of any line of the list and Raleigh is to be matched
with any part of any line of the list subsequent to the
part which *Foo* matched.  That is, *Foo*Raleigh* would
match Foo$Raleigh or Foo_Raleigh but not Raleigh$Foo nor
Raleigh_Foo.

>if I wanted to search for Foo anywhere in a
>line plus Raleigh at the beginning of a line, would I need to do:
>*Foo* Raleigh*
>(ie, have a space separator?)

The substrings matching rule doesn't support such assertions.
As a substrings assertions, *Foo* Raleigh* and *Foo*Raleigh*
will match the same entries as the extra leading space in
the second any string (in the first assertion) is simply
ignored.

>Anyway, for the List match aspect, do you just try to match each piece and
>if all of the pieces match, then you have a list match?  Like you would go
>through looking for a match for *Foo*.  When you found it, move in to
>the Raleigh part and continue on looking for it.  If you find the Raleigh
>part, great, you have a match.  Otherwise, nope?

It's unclear to me that your description is correct.

caseIgnoreListSubstringsMatch has the same basic substrings
semantics as caseIgnoreSubstringsMatch.  Instead of matching
against a single directory string, the former matches against
a list of directory strings (lines).  The initial substring, if
asserted, must match the beginning of the first line.  The
final substring, if asserted, must match the end of the last
line.  Each any substrings match in between.  The matched
portions must not overlap each other, must not span lines,
and must appear in the same order as the substrings.  Multiple
matched portions, however, may be in the same line... and
some lines may have no matched portions.

Kurt