Re: [PATCH] Add wildcard matching to substitute-path rules

[Max Yvon Zimmermann <max.yvon.zimmermann@campus.tu-berlin.de>]

Thank you.

>> On DOS-based systems both backslashes and forward slashes are valid path separators. So while Windows users COULD write their paths as \\path\\to\\, /path/to/ would work as well. This behavior is not new, the previous version behaved similarly. New is that to match a backslash from the GDB command line you would have to escape a backslash twice (because the CLI already unescapes backslashes). But because everyone can just continue to use forwards slashes, I think this should be fine.
> 
> So extra \-escaping will still be needed for DOS-based filesystems.  I
> think this should be mentioned in the documentation.

Actually, this is already mentioned in the documentation. But maybe it can be made a bit clearer. On the other hand, I really do not want to encourage the extra \-escaping. I am thinking of writing something like this instead:

"On DOS-based file system, you are encouraged to use '/' as the path separator within your patterns. This avoids escaping the '\' characters and would still match against file names that use '\' as the path separator. For instance, the pattern 'C:/foo/*' would still match 'C:\foo\bar'."

>> I realize now that /usr/*/include is actually a terrible example for this feature. I will change the example to avoid confusion. However it is correct that two files from distinct directories COULD accidentally get matched. But you could argue that this is already the case. Let's say we set the following two rules:
>>
>> set substitute-path /foo/include /mnt/include
>> set substitute-path /bar/include /mnt/include
>>
>> Then we could run into exactly the same issue.
> 
> The difference here is that the two lines above must be explicitly
> written by the user, whereas the wildcard rule could catch another
> directory unintentionally.
> 
>> I would also like to point out that the rule selection is unaffected by this patch. To quote from the documentation: "In the case when more than one substitution rule have been defined, the rules are evaluated one by one in the order where they have been defined. The first one matching, if any, is selected to perform the substitution."
> 
> To me, this means that the two-line example you've shown is processed
> in a predictable way, by only using the first one if both match,
> whereas a wildcard rule will cause unpredictable results, because the
> order in which files are compared against a wildcard is undefined.
> Right?

No, rules that use wildcards are still processed in a predictable way. If we set the following two rules (and in that order!):

set substitute-path /foo/include /path/to/foo
set substitute-path /*/include /path/to/somewhere

Then any file names matching '/foo/include' would be rewritten to '/path/to/foo' and NOT '/path/to/somewhere'. Even though any file name matching '/foo/include' would of course also match '/*/include'. The rule selection is entirely based on the order of their definition.

Also, in the example I stated in my last reply, no file name that matches '/foo/include' would ever match '/bar/include'. The point I was trying to get across was that two unrelated files can already be mapped onto the same file (accidentally).