[PEAR-BUG] Doc #20369 [Fbk]: Unclear usage of regexes in exclude patterns

Edit report at https://pear.php.net/bugs/bug.php?id=20369&edit=1

 ID:               20369
 Updated by:       [email protected]
 Reported By:      pear at larsheber dot de
 Summary:          Unclear usage of regexes in exclude patterns
 Status:           Feedback
 Type:             Documentation Problem
 Package:          PHP_CodeSniffer
 Package Version:  2.0.0RC1
 PHP Version:      Irrelevant
 Assigned To:      squiz
 Roadmap Versions: 
 New Comment:

I committed the change for part 2 here: 
https://github.com/squizlabs/PHP_CodeSniffer/commit/587c70b23740802ae029df6a5d
0ddfd7d4f39a1b


Previous Comments:
------------------------------------------------------------------------

[2014-08-21 00:38:00] squiz

1. Sorry, but I'm not going to change this. I don't want to add even
more complexity. 
If you know that * is replaced by .* you should be able to work around
it with the 
current system. I don't think there is serious misbehaviour here.

2. I'll get these checks working the same way.

------------------------------------------------------------------------

[2014-08-18 13:07:27] pittiplatsch

1.
Of course I see your reason to avoid the BC break.
However, as I stated out, there are cases where the current
implementaion leads to serious misbehaviour :-(
I already thought about a solution. What about adding a new attribute to
the "exclude pattern" element, which - if not set - for BC is something
like "convenience" or "easyPattern" or sth. like this, whereas you can
explicitly set it to "plain", "regex" or similar which leads to given
exclude pattern being handled via regex evaluation as-is.

2.
Yep, that's exactly what I mean. I already discovered what you just
wrote where the DIR-SEP replacement doesn't take place.
From architectural point of view, this functionality should just be
consolidated into a single method :-)
[As a side note: This behaviour could be made configurable as well via
xml element attribute ("cleverDirSep" or the like)]

------------------------------------------------------------------------

[2014-08-14 07:44:21] squiz

-Status:      Open
+Status:      Feedback
-Assigned To:
+Assigned To: squiz
1. Comma is used to separate patterns on the command line, so you need
to 
escape any commas you use in the patterns themselves. So I remove the
escape 
chars for commas only. The * -> .* change is just a convenience thing,
as was the 
norm when I added this feature years ago. It's easier to just do --
exclude=*/tests/*. Removing this would be a huge backwards compatibly
break, so 
I'd never do it.

2. I assume you mean this code from where files are excluded:
if (DIRECTORY_SEPARATOR === '\\') {
    $replacements['/'] = '\\\\';
}

That code isn't present when doing sniff exclusions. I don't think there
is any 
reason for that and it can be added in easily. Before I do, is this what
you are 
talking about specifically?

------------------------------------------------------------------------

[2014-08-11 08:57:11] pittiplatsch

Description:
------------
Hello,
due to quite incomplete docs I'm trying to find out the exact
possibilities of exclude patterns by inspecting the sources.

However, some questions remain:
1.
Obviously, exclude patterns are rendered as regexes. In some issues
concerning excl-pat's regular expression syntax is 

recommended (e.g. issue #19648).
However, what's the point then of hard-coded string-replace of "\\," to
"," and "*" to ".*" before processing the regex?
a)
I see some convenience to simply use "*" - but this leads to some
regexes failing where they shouldn't:
The regex "^application/test.*\.php" is changed to
"^application/test..*\.php" which leads the file "application/test.php"


to fail although my original regex includes this file!
b)
What about the "\\," to "," thing?

2.
Why are exclude patterns processed differently for global use and
per-sniff?
I have the concrete problem that (using Windows) for global usage both
patterns "application\\" and "application/" work 

perfectly fine, while on per-sniff basis only "application\\" works
which obviously prevents portability to *NIX systems.

------------------------------------------------------------------------


-- 
Edit this bug report at https://pear.php.net/bugs/bug.php?id=20369&edit=1