Problem
The Debian (and RPM) packages ship the raw Phar as the executable:
# utils/wp-cli-updatedeb.sh
mv ../wp-cli.phar usr/bin/wp
chmod +x usr/bin/wp
So /usr/bin/wp is the Phar itself and launches via its #!/usr/bin/env php shebang, i.e. the first php on PATH. Neither WP_CLI_PHP nor WP_CLI_PHP_ARGS is ever read, because the shell wrapper that reads them (bin/wp in wp-cli/wp-cli) is not part of a Phar install. Reported downstream in wp-cli/wp-cli#5886.
This has always been the case (verified against the 2.5.0, 2.9.0 and 2.11.0 .deb artifacts, all of which install a Phar whose first line is #!/usr/bin/env php). It is not a regression from wp-cli/wp-cli#5672, which only corrected what wp cli info reports.
Proposed fix
Stop shipping the bare Phar as /usr/bin/wp. Instead:
- Install the Phar at a stable path, e.g.
/usr/share/wp-cli/wp-cli.phar.
- Install a launcher at
/usr/bin/wp implementing the existing bin/wp semantics:
#!/usr/bin/env sh
php="${WP_CLI_PHP:-$(command -v php)}"
export WP_CLI_PHP_USED="$php"
exec "$php" $WP_CLI_PHP_ARGS /usr/share/wp-cli/wp-cli.phar "$@"
This makes WP_CLI_PHP select the interpreter, lets WP_CLI_PHP_ARGS pass -c / -n / -d before the Phar, and makes the php.ini used line in wp cli info correct automatically (the chosen interpreter loads its own config). No change to core get_php_binary() and no reversal of wp-cli/wp-cli#5672 is required.
Compatibility notes (why 3.0.0)
The package layout changes: /usr/bin/wp stops being the Phar. Needs review of:
wp cli update / self-update behavior against a launcher + separate Phar path.
- Phar-path reporting in
wp cli info.
- Upgrades from older packages that shipped the Phar directly at
/usr/bin/wp.
- Packaging tests and the
md5sums / man-page generation steps in the build script.
- Applying the same change to the RPM build.
Acceptance
- Default invocation (no vars) still uses
PATH php.
WP_CLI_PHP=/usr/bin/php8.1 wp cli info reports and runs under that binary.
WP_CLI_PHP_ARGS="-n" and WP_CLI_PHP_ARGS="-c /path/php.ini" take effect.
- Clean upgrade from a pre-launcher package.
Problem
The Debian (and RPM) packages ship the raw Phar as the executable:
# utils/wp-cli-updatedeb.sh mv ../wp-cli.phar usr/bin/wp chmod +x usr/bin/wpSo
/usr/bin/wpis the Phar itself and launches via its#!/usr/bin/env phpshebang, i.e. the firstphponPATH. NeitherWP_CLI_PHPnorWP_CLI_PHP_ARGSis ever read, because the shell wrapper that reads them (bin/wpin wp-cli/wp-cli) is not part of a Phar install. Reported downstream in wp-cli/wp-cli#5886.This has always been the case (verified against the 2.5.0, 2.9.0 and 2.11.0
.debartifacts, all of which install a Phar whose first line is#!/usr/bin/env php). It is not a regression from wp-cli/wp-cli#5672, which only corrected whatwp cli inforeports.Proposed fix
Stop shipping the bare Phar as
/usr/bin/wp. Instead:/usr/share/wp-cli/wp-cli.phar./usr/bin/wpimplementing the existingbin/wpsemantics:This makes
WP_CLI_PHPselect the interpreter, letsWP_CLI_PHP_ARGSpass-c/-n/-dbefore the Phar, and makes thephp.ini usedline inwp cli infocorrect automatically (the chosen interpreter loads its own config). No change to coreget_php_binary()and no reversal of wp-cli/wp-cli#5672 is required.Compatibility notes (why 3.0.0)
The package layout changes:
/usr/bin/wpstops being the Phar. Needs review of:wp cli update/ self-update behavior against a launcher + separate Phar path.wp cli info./usr/bin/wp.md5sums/ man-page generation steps in the build script.Acceptance
PATHphp.WP_CLI_PHP=/usr/bin/php8.1 wp cli inforeports and runs under that binary.WP_CLI_PHP_ARGS="-n"andWP_CLI_PHP_ARGS="-c /path/php.ini"take effect.