phpcs.phar executable being treated as a directory by itself

[davidfavor]

Describe the bug phpcs.phar being treated as a directory by phpcs.phar

Code sample

phpcs --version

Custom ruleset

None

To reproduce Steps to reproduce the behavior:

1. phpcs --version
2. See error message displayed

   # phpcs.phar --version
   PHP PHP_CodeSniffer\Exceptions\DeepExitException:  PHP_CodeSniffer version 3.7.1 (stable) by Squiz (http://www.squiz.net)
   in phar:///root/bin/phpcs.phar/src/Config.php on line 3
   PHP Stack trace:
   PHP   1. {main}() /root/bin/phpcs.phar:0
   PHP   2. PHP_CodeSniffer\Runner->runPHPCS() /root/bin/phpcs.phar:6
   PHP   3. PHP_CodeSniffer\Config->__construct($cliArgs = *uninitialized*, $dieOnUnknownArg = *uninitialized*) phar:///root/bin/phpcs.phar/src/Runner.php:3
   PHP   4. PHP_CodeSniffer\Config->setCommandLineValues($args = [0 => '--version']) phar:///root/bin/phpcs.phar/src/Config.php:3
   PHP   5. PHP_CodeSniffer\Config->processLongArgument($arg = 'version', $pos = 0) phar:///root/bin/phpcs.phar/src/Config.php:3
   PHP_CodeSniffer version 3.7.1 (stable) by Squiz (http://www.squiz.net)

Expected behavior A clear and concise description of what you expected to happen.

Versions (please complete the following information):

• OS: Linux Jammy + all updates
• PHP: 8.2.1 + all updates
• PHPCS: 3.7.1
• Standard: Defaults

Additional context I do notice the same installation, followed off GitHub project page, works on Ubuntu Focal + fails on Ubuntu Jammy.

The error seems to indicate no OS involvement + this is the only difference between working/failing installs.

[jrfnl]

Just to see if I understand the issue correctly: Could you try calling it like php phpcs --version ?

If that works, I kind of suspect a server configuration issue where phar files are not recognized as php "files".

[davidfavor]

Just as ticket description says above. Refer to the error output.

Notice the attempt to access a file... so /root/bin/phpcs.phar is being treated as a directory.

/root/bin/phpcs.phar/src/Config.php

This happens running either of...

phpcs.phar --version
php -f phpcs.phar --version

And phpcs survives, meaning the command continues to run.

So phpcs + phpcbf are still usable.

What's required is to just ignore the error message.

And... this is very ugly + best have some fix or workaround.

I'm pretty handy on the command line, so pass along whatever potential fixes you'd like me to try + I'll return the results.

[jrfnl]

I cannot reproduce this issue and don't have access to Ubuntu Jammy.

I suspect this may have something to do with something in the php.ini file disabling the use of a custom error handler (which PHPCS has and which presents the messages in a tidy fashion).

I'm not sure what you expect PHPCS to do about this. This very much sounds like a PHP config issue.

[fredden]

I've tested the following on both ubuntu:jammy and ubuntu:focal docker images; both showed expected results.

docker run --rm -it ubuntu:jammy # or ubuntu:focal
apt-get update
apt-get install -y lsb-release curl php-cli php-xml
curl -OL https://squizlabs.github.io/PHP_CodeSniffer/phpcs.phar
lsb_release -a
php --version
php phpcs.phar --version

Screen-shot of output


The error seems to indicate no OS involvement + this is the only difference between working/failing installs. [...] I'm pretty handy on the command line, so pass along whatever potential fixes you'd like me to try + I'll return the results.

@davidfavor are you able to provide details for how to reproduce this issue using clean docker images as suggested here?