I create this RFE as suggested in this stackoverflow link, which includes a link to the original problem, that I'll try to summarize here.
In symfony 5.4, and since it's TLS and it's still more than 2 years till the end of life, I (and think that many people) face the problem that having to develop with the today stable php version 7.4 in servers but the 8 version being available to test features, etc, it's very common to have in development environments at least both versions installed. The symfony cli solved this problem by creating a .php-version file, so starting the server with an specific php version indicated in this file, the symfony cli, when using server:start, starts the indicated version instead of the default one. This behaviour is great, but I miss it with bin/console. As explained in starckoverflow, I expected that by requiring the 5.x version of symfony when creating a new project, bin/console somehow, including creating a .php-version file, would be aware of not to use other versions, generating code not understandable by the symfony cli. I don't think that anyone, when decides to specify a .php-version file, wants to run a different version other than that very one. It could be my fault not being aware of this, but anyway, I propose a bash script to act as a wrapper, being a simple solution to solve this annoying situation without worring for having to type "long" commands to override the default php version (not to mention what could happen if you ever forget to use the "long" command) and stick on the specified php version indicated in the .php-version file any time I have to use some console commands.
Inside the wrapper script there are instructions to use it, which involve to rename the original bin/console php script to bin/console.php, and some ways to run the script.
Here is the wrapper script (which anybody can enhance, of course):
#!/bin/bash
# This script is to be used under the terms of GPL 3.0
# The purpose is to use exactly the same commands in bin/ folder
# but taking care of the .php-version file just like the
# symfony cli does, and stick on that version instead of
# having to run the default system-wide php binary or
# having to prepend the specific version for each console command.
#
# To take advantage of this:
# 1) Rename bin/console to bin/console.php
# 2) Repeat for every php script you want to use this way
# 3) Save this file and name it bin/wrapper.sh and give execution permissions
# to this script (chmod +x bin/wrapper.sh)
# 4) Create a symlink for every renamed file, using the old name,
# that points to the wrapper (ln -s wrapper.sh bin/oldname)
#
# Of course, you can skip this last step by directly saving this file as bin/console in 3)
RUNFILE="${0}.php"
if [ -f $RUNFILE ];then
PHP=$(which php)
VERSIONFILE=".php-version"
if [ -f $VERSIONFILE ];then
_VERSION=$(cat $VERSIONFILE)
_PHP=$(which php${_VERSION})
if [[ ${_PHP} ]];then
PHP=$_PHP
fi
fi
$PHP $RUNFILE [email protected]
else
echo "No such file $RUNFILE"
exit 1
fi
Before: $ php7.4 bin/console ...whatever...
After: $ bin/console ...whatever...
If I’m reading this correctly, this script appears to assume that PHP binaries, or at least their links, are named php7.4 or php8.0 which is definitely not always true.
Your point is fully correct and I guess is the best solution (as long as there's previously the corresponding .php-version file), but then I think a kind of coordination is needed, because at least in Symfony controller documentation, the examples don't explain that way. For instance:
php bin/console make:controller BrandNewController
or
php bin/console make:crud Product
so, I think that as long as these docs (and maybe other documentation) seem to always rely on the default php for the console commands, some kind of "fix" is needed. Unluckily, i think that we can state that the methods explained in the documentation aren't 100% accurate. On my side, I'll try to use this way from now on.
Use symfony console to use the console, and it will also perform the version selection logic (and it will also inject env variables with the credentials for services, as done for the started server, if you use the Docker integration).
Locks are used to guarantee exclusive access to some shared resource. In Symfony applications, you can use locks for example to ensure that a command is not executed more than once at the same time (on the same or different servers). If the lock can not be acquired, the method returns false .
| Age | 13yrs |
|---|---|
| Vendor | symfony |
| Repo Name | symfony |
| Primary Language | PHP |
| Default Branch | 6.3 |
| Last Update | 1 month ago |
symfony/event-dispatcher
symfony/http-kernel
symfony/css-selector
symfony/translation
symfony/dependency-injection
symfony/cache
symfony/flex
symfony/framework-bundle
symfony/maker-bundle
symfony/validator
symfony/polyfill
symfony/demo
symfony/symfony-docs
symfony/webpack-encore
symfony/security-core
symfony/security-http
symfony/polyfill-php80
symfony/security
symfony/messenger
symfony/workflow
symfony/password-hasher
symfony/ux
symfony/recipes-contrib
symfony/mercure
symfony/security-acl
symfony/rate-limiter
symfony/clock
symfony/stimulus-bridge
symfony/mailgun-mailer
symfony/amazon-mailer