Check failes on symlink directory

[NicoCa]

Hi,
with PHP_Codesniffier 3.0.0 the check fails on a directory which is a symlink to a directory containing only .orm.yml files.
Message:

WARNING  No PHP code was found in this file and short open tags
 are not allowed by this install of PHP. This file may
be using short open tags but PHP does not allow them.

Is this a bug or is there new configuration that needs to be done?

Any help would be very much appreciated.

Thanks in advance!

[gsherwood]

You don't specifically say if PHPCS is running properly when you point it at the directory itself and not the symlink. Have you tried this?

I'm trying to figure out if this is a symlink issue or if this is just PHPCS checking files and not finding any non-PHP content.

It would also be good if you could post the output of phpcs -vv ... as that will show what content PHPCS is finding in the files.

[NicoCa]

Thanks for your fast reply.

The directory itself is beeing processed fine.

The verbose output (I hope that is what you ment):

Processing doctrine 
        *** START PHP TOKENIZING ***
        *** END PHP TOKENIZING ***
        *** START TOKEN MAP ***
        *** END TOKEN MAP ***
        *** START SCOPE MAP ***
        *** END SCOPE MAP ***
        *** START LEVEL MAP ***
        *** END LEVEL MAP ***
        *** START ADDITIONAL PHP PROCESSING ***
        *** END ADDITIONAL PHP PROCESSING ***
[PHP => 0 tokens in 0 lines]... 
DONE in 0ms (0 errors, 1 warnings)

FILE: /home/.../config/doctrine
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 1 | WARNING | No PHP code was found in this file and short open tags are not allowed by this install of PHP. This file may be using short open tags but PHP does not allow them.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

/home/.../config/doctrine is the symlink directory.

[gsherwood]

That verbose output shows that PHPCS is processing the symlink as a file instead of a directory. When I create a test symlink dir setup, it works fine and PHPCS iterates through the directory content of the symlink as if it was a real directory.

The only thing I can think of is that maybe the perms of the symlink are incorrect and can't be followed, but I'm really not sure.

You should be able to run PHPCS directly on /home/.../config/doctrine/something.orm.yml directly, so maybe try that to see if the file path is even resolvable by PHP.

[dennisgawrisch]

I can reproduce this on macOS 10.12.6:

$ php -v
PHP 5.6.30 (cli) (built: Mar 11 2017 09:56:27) 
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with Xdebug v2.5.5, Copyright (c) 2002-2017, by Derick Rethans
$ phpcs --version
PHP_CodeSniffer version 3.0.2 (stable) by Squiz (http://www.squiz.net)
$ mkdir test-phpcs-symlink
$ cd test-phpcs-symlink/
$ mkdir realdir
$ ln -s realdir symlink
$ ls -l
total 8
drwxr-xr-x  2 denyspopov  staff  68  8 Aug 10:09 realdir
lrwxr-xr-x  1 denyspopov  staff   7  8 Aug 10:10 symlink -> realdir
$ cd ..
$ phpcs -v -p --standard=PSR2 test-phpcs-symlink/
Registering sniffs in the PSR2 standard... DONE (42 sniffs registered)
Creating file list... DONE (1 files in queue)
Changing into directory /.../test-phpcs-symlink
Processing symlink [PHP => 0 tokens in 0 lines]... DONE in 0ms (0 errors, 1 warnings)

FILE: /.../test-phpcs-symlink/symlink
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 1 | WARNING | No PHP code was found in this file and short open tags are not allowed by this install of PHP. This file may be using short open tags but PHP does not allow them.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Time: 61ms; Memory: 6.5Mb

But on Linux the same situation is fine:

$ docker run --rm -it php:5.6 bash

# curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
# apt-get update && apt-get install git
# composer global require squizlabs/php_codesniffer

# php -v
PHP 5.6.31 (cli) (built: Aug  3 2017 22:55:58) 
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
# ~/.composer/vendor/bin/phpcs --version
PHP_CodeSniffer version 3.0.2 (stable) by Squiz (http://www.squiz.net)

# mkdir test-phpcs-symlink
# cd test-phpcs-symlink/
# mkdir realdir
# ln -s realdir symlink
# ls -l
total 4
drwxr-xr-x 2 root root 4096 Aug  8 08:36 realdir
lrwxrwxrwx 1 root root    7 Aug  8 08:36 symlink -> realdir
# cd ..
# ~/.composer/vendor/bin/phpcs -v -p --standard=PSR2 test-phpcs-symlink/
Registering sniffs in the PSR2 standard... DONE (42 sniffs registered)
Creating file list... DONE (1 files in queue)
Changing into directory /test-phpcs-symlink
Processing symlink [PHP => 0 tokens in 0 lines]... DONE in 0ms (0 errors, 0 warnings)
Time: 51ms; Memory: 4.75Mb

[gsherwood]

But on Linux the same situation is fine:

I think it's probably doing the exact same thing on Linux but you've got short open tags allowed by that PHP instance. PHPCS still sees the symlink as a single file (1 files in queue) so it would be processing it in the same way.

It is possible that the difference between my test setup and your setup is that I'm pointing PHPCS directly at the symlink and not a directory higher up. I'll have a play around and see if this is the case. Either way, thanks a lot for doing that testing and providing such detailed steps and output. It's very helpful.

[gsherwood]

I've allowed symlinks to be followed when generating the file list, which fixes this problem.