[PEAR-BUG] Doc #20369 [Fbk->Csd]: 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
+Status:           Closed
 Type:             Documentation Problem
 Package:          PHP_CodeSniffer
 Package Version:  2.0.0RC1
 PHP Version:      Irrelevant
 Assigned To:      squiz
 Roadmap Versions: 
 New Comment:

-Status: Feedback
+Status: Closed
1. I had actually never documented that ignore patterns can actually be
regular 
expressions (although I've always supported them), but I have done so
now and put 
in a note about the * replacement. The docs are here: 
https://github.com/squizlabs/PHP_CodeSniffer/wiki/Advanced-Usage#ignoring-files-
and-folders

2. Yes, it will be in the next 2.0RC2 (probably September) and then in
2.0 stable 
(probably Oct).


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

[2014-08-22 11:09:17] pittiplatsch

1.
Ok, than the usage of exclude patterns (and its limitations) should be
clearly documented I think.
Due to CS's wide usage - even for auto-deployment - its usage and
powerful capabilities shouldn't be hazy ;-)

2.
Thx, so this will be available for final 2.0?

Thank you very much :-)

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

[2014-08-21 01:01:05] squiz

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

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

[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?

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

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=20369

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