[PATCH] xfree86: Allow InputClass entries to specify match type

[Dan Nicholson]

On Mon, Dec 6, 2010 at 5:45 PM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> On Mon, Dec 06, 2010 at 05:47:02AM -0800, Dan Nicholson wrote:
>> On Sun, Dec 5, 2010 at 9:29 PM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
>> > On Thu, Dec 02, 2010 at 06:19:15AM -0800, Dan Nicholson wrote:
>> >> The InputClass Match* entries are currently hardwired to offer a certain
>> >> variant of comparison for matching. For example, the MatchProduct entry
>> >> uses substring match. Add a second optional argument to the entry to
>> >> allow the match type to be specified.
>> >>
>> >>       MatchProduct "foo*" "pattern"
>> >>
>> >> The available match types are "string", "istring", "substring",
>> >> "isubstring", "path" and "pattern". See xorg.conf(5) for more details.
>> >> If no type is supplied, the previous default is used.
>> >
>> > I wonder if it is possible to support sed- or grep-like matching instead of
>> > adding match types like this?
>> >
>> > something like?
>> >    MatchProduct "s/pattern/i"
>>
>> Thanks for taking a look at this.
>>
>> That would work, but it wouldn't offer the same flexibility. You'd
>> basically get the default or an unusual regex. I personally think it's
>> cleaner to specify the type (if you want), but I realize this is sort
>> stretching it as a feature.
>>
>> One of the things I intended to do was add a regex matcher. E.g.,
>>
>>     MatchProduct "TheMouse[123]" "regex"
>>
>> I can work on that now if it makes this patch seem more useful.
>
> well, my thought was mainly that this may allow us to re-use a library that
> provides this matching pattern already.
>
> afaict, the examples you have above are "s/^string$/", s/^string$/i,
> s/string/, s/string/i, (don't know about path) and s/..regex../. this is a
> pretty standard way of specifying match patterns, there's plenty of
> documentation for sed out there already, etc.

I don't think using regular expressions for everything is wise for a
couple reasons.

1. We already have configurations out there that use the boring strcmp
and strstr matches. Silently treating those as regexes will break
strings that have any of ".*?()[]".

2. We already have configurations out there that use fnmatch globbing.
There's no easy conversion between regexes and globs. I was on the rpm
mailing list a couple years ago, and the maintainer had an anecdote
about a situation like this. If you run "rpm -qa <pattern>", the
pattern was heuristically treated as either a glob or a regex based on
the characters. He did this because it was originally a regex, but too
many people didn't understand how regexes worked. I turned out most
people understood globs much better, so he put some magic in the code
to try to have both. He said he always regretted that decision and
wished he'd just picked one or the other. I would wager that most
people would rather have globbing for paths.

> my worry is that we'll come up with something else that's X specific, and
> then two releases down that's not quite enough either and we eventually end
> up with a re-implementation of sed or grep anyway, except that we then also
> have to support istring, qstring, [a-z]substring, etc.

These aren't X specific, though. They're all standard (to differing
extents) C library calls. They're just strcmp, strcasecmp, strstr,
strcasestr and fnmatch. I tried to give them "useful for
non-programmer" names, but we can refer to them by their symbol names
if that's clearer. regex(3) is also entirely standard, but we didn't
have any use for them yet.

--
Dan