Replies: 1 comment
-
|
I guess the best solution here would be to just support |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Not sure if this is a bug or intended, but I was using a CLI package that referenced the PHP_BINARY predefined constant - not the environment variable.
Most of the other predefined constants are available, but not this one.
Is this intended?
To add, the "known issues" touch the subject with Composer Scripts Referencing @php
suggesting the idea that overwriting
/usr/local/bin/phpwith a custom Bash script.This probably works, but it causes issues - for example a package like Laravels Horizon.
While the actual implementation (in this specific case) still wouldn't work if
PHP_BINARYis set to something like/usr/local/bin/frankenphp php-cli, it would be fixable (with the aforementioned Bash script) ifPHP_BINARYwould point to/usr/local/bin/php. But pointing to another executable than the one actually running the script, makesPHP_BINARYless reliable as a constant than what is intended.A quick search through some repositories on GitHub suggests that other packages as well, rely on this constant.
Beta Was this translation helpful? Give feedback.
All reactions