Valet-plus: DIR path breaks in 5.6

[capitaladot]

$ valet
Password:
Could not open input file: /cli/valet.php

[capitaladot]

This seems to be resolving to an empty string:

if [[ -L $SOURCE ]]
then
    DIR=$(php -r "echo dirname(realpath('$SOURCE'));")
else
    DIR="$( cd "$( dirname "$SOURCE" )" && pwd )"
fi

# If we are in the global Composer "bin" directory, we need to bump our
# current directory up two, so that we will correctly proxy into the
# Valet CLI script which is written in PHP. Will use PHP to do it.
if [ ! -f "$DIR/cli/valet.php" ]
then
    DIR=$(php -r "echo realpath('$DIR/../laravel/valet');")
fi

[alaa-almaliki]

I had the same thing, wrapping the $SOURCE by curly braces seems to fix the issue.

if [[ -L $SOURCE ]]
then
    DIR=$(php -r "echo dirname(realpath('$SOURCE'));") # change to DIR=$(php -r "echo dirname(realpath('${SOURCE}'));")
else
    DIR="$( cd "$( dirname "$SOURCE" )" && pwd )"
fi

This occurs on php5.6 only which seems it can not read the source like in php7

[michielgerritsen]

In my case this was caused by an segmentation fault in the php -r command. A reboot did fix it for me.

[alaa-almaliki]

This is not very practical specially when you work on various projects and need to frequently switch php versions.

[samgranger]

I'll try to reproduce this, thank you for supplying your solution @alaa-almaliki

[samgranger]

Can you try our new 1.0.19 release to see if it solves this issue?

[alaa-almaliki]

Thanks @samgranger, sorry I was away from home for a couple of days and only came back today, it seems that the issue was because the xdebug enabled on PHPSTORM. The issue happens when you are in a php 7 version, then switch to php 5.6. If you have the xdebug enabled on PHPSTORM then you will get segmentation fault or Bus error if you want to run php -r "echo 1;" and since you use the same method to get the directory of the $SOURCE, this will result in an error through valet but it is not a valet error. I am not sure how to fix the issue other than switching off the xdebug on PHPSTORM then run valet xdebug on and only then you will be able to use xdebug or run valet commands. This error was also mentioned here at stackoverflow https://stackoverflow.com/questions/29700081/composer-install-fails-with-bus-error-10/29701249#29701249

[capitaladot]

Just updated to 1.0.19, valet+ is still broken after switching to 5.6.

My laborious and annoying repair procedure is to re-install php 7.1, run valet fix, then switch back again, but there have been times where this doesn't work and I have to traverse to ~/.composer/vendor/weprovide and run valet from there.

[samgranger]

As mentioned in #229:

Can you check if ~/.composer/vendor/bin is in your systems path? You can check this by running echo $PATH.

If this is not the case, please execute the following command and restart your terminal: export PATH=$PATH:~/.composer/vendor/bin

[capitaladot]

Here's my path:

echo $PATH
/usr/local/sbin:/usr/local/sbin/sqlite:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin:/opt/X11/bin:/Users/user/.composer/vendor/bin

[mischabraam]

Hi, had the same problem when I had PHPStorm listening to xdebug connections. Stop listening fixed it, see https://stackoverflow.com/questions/29700081/composer-install-fails-with-bus-error-10

[mischabraam]

Hi @capitaladot, is 1.0.20 I've changed the way to detect the valet binary. I had a problem with PHP 5.6 here and fixed it. Can you if your problems are solved in 1.0.20 please?

[capitaladot]

Will retest.

On Tue, Aug 14, 2018, 8:46 AM Mischa Braam [e-mail] wrote:

Hi @capitaladot https://github.com/capitaladot, is 1.0.20 I've changed
the way to detect the valet binary. I had a problem with PHP 5.6 here and
fixed it. Can you if your problems are solved in 1.0.20 please?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/weprovide/valet-plus/issues/216#issuecomment-412859194,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABi1gXKaZlQbQ5URwlHwRRUvIRUBYBOEks5uQsaYgaJpZM4U_gIX
.

[capitaladot]

Seems to work a treat, thanks.

Closes #216

On Tue, Aug 14, 2018, 9:41 AM A. [e-mail] wrote:

Will retest.

On Tue, Aug 14, 2018, 8:46 AM Mischa Braam [e-mail]
wrote:

Hi @capitaladot https://github.com/capitaladot, is 1.0.20 I've changed
the way to detect the valet binary. I had a problem with PHP 5.6 here and
fixed it. Can you if your problems are solved in 1.0.20 please?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/weprovide/valet-plus/issues/216#issuecomment-412859194,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABi1gXKaZlQbQ5URwlHwRRUvIRUBYBOEks5uQsaYgaJpZM4U_gIX
.

[regularlabs]

I updated drom 1.0.19 to 1.0.20 and I now get this error:
Could not open input file: /cli/valet.php
I never had this before.

[jomurgel]

Just like @regularlabs I updated to 1.0.20 and received that same error Could not open input file: /cli/valet.php. Downgraded back to 1.0.19 and everything was fine.

[SpeedyRecovery]

Same issue as @regularlabs and @jomurgel -- was previously running 1.0.19, pulled valet-plus via the .valet-plus-destroy script by @dannygsmith, then tried to reinstall valet-plus and received the Could not open input file: /cli/valet.php error. Using 1.0.19 instead fixed the issue.

[regularlabs]

Try renaming the file (symbolic link):
/Users/.../.composer/vendor/bin/valet to /Users/.../.composer/vendor/bin/_valet
Or remove it.

[maurisource]

I installed 1.0.20 and I get the same error under [email protected]

valet install
Could not open input file: /cli/valet.php

echo $PATH

/usr/local/opt/[email protected]/sbin:/usr/local/opt/[email protected]/bin:/usr/local/opt/gettext/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/local/bin::/usr/local/opt/gettext/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/local/bin:/usr/local/opt/gettext/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/local/bin:/usr/local/opt/gettext/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/local/bin:/usr/local/opt/gettext/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/local/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin:$PATH:/Users/maurisource/.composer/vendor/bin:/Users/maurisource/.composer/vendor/bin:/Users/maurisource/.composer/vendor/bin:/Users/maurisource/.composer/vendor/bin:~/.composer/vendor/bin:/Users/maurisource/.composer/vendor/bin

Here's the Php infos:

which php
/usr/local/opt/[email protected]/bin/php

Is there a solution for this? Or am I missing something?

[mischabraam]

Thanks, will get on it

[mischabraam]

Hi, just released 1.0.21 with a double check fix.

[capitaladot]

Re-tested on 5.6 in 1.0.21; still good (since 1.0.20)!

[maurisource]

Thanks @mischabraam I'm able to run through installation just fine since the double check fix released in 1.0.21

[IngWARP]

I run in to this problem running valet-plus 1.0.23 on macOS 10.14.1 trying php 5.6.38
After disabling opcache in '/usr/local/etc/php/5.6/conf.d/ext-opcache.ini' I was able to run 5.6