Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 3.7.2

Bug #18250 --standard with relative path skips Standards' "implicit" sniffs
Submitted: 2011-02-08 04:14 UTC
From: mrten Assigned: squiz
Status: Closed Package: PHP_CodeSniffer (version 1.3.0RC2)
PHP Version: 5.3.1 OS: Unix
Roadmaps: (Not assigned)    
Subscription  


 [2011-02-08 04:14 UTC] mrten (Mr ten)
Description: ------------ I wrote my own ruleset.xml that does not explicitly refer to the sniffs in the directory structure it's in. When I run phpcs with a relative path to that ruleset.xml however, it seems to skip the rules in the Standard directory. For brevity I wc'd the output: mrten@kimiko:~/www$ phpcs --standard=.include/Codesniffer/IDD/ruleset.xml ~/www/.include/it_lib.php | wc 61 665 4334 mrten@kimiko:~/www$ phpcs --standard=/home/mrten/www/.include/Codesniffer/IDD/ruleset.xml ~/www/.include/it_lib.php | wc 111 1339 8126 and with -s for the sniff name: mrten@kimiko:~/www$ phpcs --standard=/home/mrten/www/.include/Codesniffer/IDD/ruleset.xml -s ~/www/.include/it_lib.php | grep IDD\. | wc 50 500 5084 mrten@kimiko:~/www$ phpcs --standard=.include/Codesniffer/IDD/ruleset.xml -s ~/www/.include/it_lib.php | grep IDD\. | wc 0 0 0 Expected result: ---------------- That the relative and absolute path give the same results for --standard, either way.

Comments

 [2011-02-15 11:27 UTC] squiz (Greg Sherwood)
You don't need to specify the ruleset.xml file if you have your own standard like that. So you can do: phpcs --standard=.include/Codesniffer/IDD ~/www/.include/it_lib.php Leaving it out works for me, but specifying the relative path to a rulset.xml file that is in a standard does not work for me. So I've been able to replicate your issue. Just need to look into why specifying a rulset.xml file explicitly does not work, but only when using a relative path.
 [2011-02-15 11:37 UTC] squiz (Greg Sherwood)
-Status: Open +Status: Closed -Assigned To: +Assigned To: squiz
This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.