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

Dan Nicholson dbn.lists at gmail.com
Wed May 25 05:42:18 PDT 2011

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.


More information about the xorg-devel mailing list