CLI PHP Version is not the one which is expected

[DavidLambauer]

When I run php bin/mageno dev:test:run integration, an exception is thrown. The Exception Trace has says something like:

Next Magento\Framework\Exception\LocalizedException: Command returned non-zero exit code:
`/usr/local/Cellar/php70/7.0.15_8/bin/php -f '/Volumes/Data/Entw.../bin/magento' setup:uninstall -vvv -n --magento-init-params='MAGE_DIRS[etc][path]=/Volumes/Data/.../dev/tests/integration/tmp/sandbox-0-7090f5f4301a9cb51238b3c3395ab07e/etc&MAGE_DIRS[var]...

I am wondering, why the php binary under /usr/local/Cellar is used. The result of which php is php: aliased to /Applications/MAMP/bin/php/php7.0.13/bin/php -d memory_limit=-1

Why doesn't Magento uses the PHP Version of my choice?

[miguelbalparda]

I don't think this is related to Magento. What's the output of php -v?

[DavidLambauer]

The output of the php -v is my aliased php-bin which differs from the one I entered above. Magento seems to pick another php version instead of the one it was called from.

[miguelbalparda]

I'd like to see the output if possible, something like this.

michael@michael-HP-Pavilion-15-Notebook-PC:~$ php -v
PHP 7.0.8-0ubuntu0.16.04.3 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.8-0ubuntu0.16.04.3, Copyright (c) 1999-2016, by Zend Technologies

[DavidLambauer]

There you go
PHP 7.0.13 (cli) (built: Dec 15 2016 18:01:10) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies with Xdebug v2.5.0, Copyright (c) 2002-2016, by Derick Rethans

[miguelbalparda]

What do you get with echo $PATH?

[DavidLambauer]

/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:

[miguelbalparda]

Okey last one. Try creating a test.php file with
<?php phpinfo() ?>
in it and then run
php -f test.php | grep "PHP Version"

[DavidLambauer]

/Volumes/Data/Entwicklung/Workspace/netz98/Shops/DemoShop ᐅ php -f test.php | grep "PHP Version"
PHP Version => 7.0.13

[miguelbalparda]

Okey I found why this is happening. There is a new PHP process being spawned for this command in particular (and probably for other commands as well). I'm not sure how to fix but at least this is a start.

[DavidLambauer]

I guess, it's because the new process doesn't has a shell so the "standard" user configuration is not loaded. So in this case, the default PHP Binary is loaded? Maybe Magento should pass the users config to the new php process call?

[miguelbalparda]

Probably that's the case, yes. I'm checking to see if there is a way to handle this differently, maybe using the output of which php and then using that file instead of a raw php call.

[DavidLambauer]

I'll do some research as well. This might be a problem other Frameworks/Shops faces too.

[miguelbalparda]

I can't reproduce your issue but maybe you can try using PHP_BINARY instead of the raw php call, it should return the path of the binary in use to excecute the current request, which seems to be the one you need.

[miguelbalparda]

Something like

<?php 
$command = PHP_BINARY." -v";

$command_1 = passthru($command, $output);
?>

worked for me

michael@michael-HP-Pavilion-15-Notebook-PC:~$ php -f test.php 
PHP 7.0.8-0ubuntu0.16.04.3 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.8-0ubuntu0.16.04.3, Copyright (c) 1999-2016, by Zend Technologies

[DavidLambauer]

Yepp, PHP_BINARY did the trick! 👍

The command call is now:

$command = PHP_BINARY . ' ' . BP . '/' . $vendorDir . '/phpunit/phpunit/phpunit ' . $options;

Do I open a PR for that?