mirror of
https://ghproxy.net/https://github.com/wp-cli/wp-cli-bundle.git
synced 2026-07-26 12:36:58 +08:00
83d3dc312aThe Debian and RPM packages shipped the Phar directly as /usr/bin/wp, so it launched through its `#!/usr/bin/env php` shebang and never consulted WP_CLI_PHP or WP_CLI_PHP_ARGS. Those variables are only read by the bin/wp shell wrapper, which is not part of a Phar install, so a packaged wp-cli has never been able to select its PHP interpreter. Reported in wp-cli/wp-cli#5886. Install the Phar to /usr/share/wp-cli/wp-cli.phar and ship a small POSIX-sh launcher at /usr/bin/wp that selects the interpreter from WP_CLI_PHP (falling back to the php on PATH), exports WP_CLI_PHP_USED, and passes WP_CLI_PHP_ARGS through, mirroring the semantics of wp-cli's bin/wp. The launcher is generated inline because the deployment workflow downloads the build scripts standalone. `wp cli update` keeps working: it resolves the Phar via argv[0], so it rewrites /usr/share/wp-cli/wp-cli.phar and leaves the launcher untouched. Also replace the ls-only package verification steps with smoke tests that assert the package layout and that the launcher actually honors WP_CLI_PHP. Fixes #1078 |
||
|---|---|---|
| .. | ||
| amp-paths.txt | ||
| find-php | ||
| get-package-require-from-composer.php | ||
| make-phar-spec.php | ||
| make-phar.php | ||
| test-phar-download | ||
| update-phar | ||
| wp-cli-rpm.spec | ||
| wp-cli-updatedeb.sh | ||
| wp-cli-updaterpm.sh | ||
