[PATCH xfree86] Signed-off-by: Oleh Nykyforchyn <oleh.nyk at gmail.com>

[Peter Hutterer]

On Wed, May 25, 2011 at 05:42:18AM -0700, Dan Nicholson wrote:
> On Tue, May 24, 2011 at 8:42 AM, Oleh Nykyforchyn <oleh.nyk at gmail.com> wrote:
> > On Tue, 24 May 2011 05:54:33 -0700
> > Dan Nicholson <dbn.lists at gmail.com> wrote:
> >
> >> The man page does say what type of matching each uses, but it's still
> >> not that discoverable.
> > You are right, it's my fault that I missed this info.
> >
> >> > What do You think about such an approach?
> >>
> >> Frankly, I'm not crazy about it for two reasons. First, it's another
> >> magic sequence to parse out and handle and attempt to explain to
> >> people. The |regex| syntax is something new that no one would know
> >> about. The only regex syntax I can think of that applies and people
> >> are familiar with is awk's /regex/, and the /s would conflict with
> >> other valid uses of the argument.
> > We can point everybody to 'man 7 regex'.
> 
> No, it's not the syntax of the regex I'm worried about. If you know
> what regex means, I don't need to tell you how to build one. I'm
> talking about the syntax that tells the server "here's a regex and not
> an innocent string you've been accepting for a while, really". That's
> the part where you guys are proposing putting magic characters in the
> string and I'm saying that's silly because we can just have another
> argument that says "regex" and be completely unambiguous about it.
> 
> >> Second, what if I as a user have the
> >> reasonable thought that I want to have multiple regexs to match
> >> against like the non-regex matching? MatchProduct "foo|bar" works, but
> >> why not MatchProduct "|foo|bar|"?
> > "foo|bar" is a pretty legal regex, hence the both variants are equivalent.
> 
> Except the first is not supposed to be a regex! It's perfectly legal
> right now to put either of those in a configuration file. What they
> mean is that the product name should have either "foo" or "bar" in it.
> 
> >> Not to mention that you can
> >> currently have "|foo|" and the code will just treat it as a single
> >> normal argument (run that through strtok with '|' as the delimiter).
> > You are right again. But my suggestion is to remove outmost '|' _before_
> > running strtok().
> 
> Yes, that's how you would parse it. Unfortunately, someone might have
> "|/foo|" in their working configuration right now and suddenly it will
> mean something completely different.

perfect is the enemy of good. If you find a user that really had exactly
this use-case, let me know and I'll buy them a beer to help get over it  :)

I like your argument about the optional third parameter though. If we just
make "regex" this parameter, we don't need magic escape sequences and can
allow 

MatchProduct "foo|bar"
and 
MatchProduct "foo|bar" "regex"

Cheers,
  Peter