Unresolvable installed_paths can lead to open_basedir errors

[ndm2]

Install paths defined via the installed_paths configuration option do sometimes contain relative paths that may not exist depending on the current environment.

Resolving such non-existent paths causes false to be included in the results, which when used for looking up files/folders, can cause wrong locations to be looked up, and/or errors being thrown. \PHP_CodeSniffer\Util\Standards::getInstalledStandardDetails() would for example look for /ruleset.xml, ie in the root of the current drive, which could trigger an open basedir restriction error.

[jrfnl]

IMO this is a valid fix.

I wonder: should a notice be shown to the user about unresolved paths to help debugging ?

[ndm2]

@jrfnl In my experience, I've mostly seen possibly non-existent paths when additional locations are being defined as a fallback. So I'm not sure, looking at for example getInstalledStandardDetails(), non-existent/accessible standard paths are deliberately silently stepped over, introducing notices would break with that... or are you maybe referring to output in verbose mode?

As far as I can tell, non existent paths would always finally trigger an error when a non existent sniff is referenced, one would then receive a message like:

ERROR: Referenced sniff "XYZ" does not exist

[gsherwood]

Fix looked good to me too. Thanks a lot for finding and fixing this.