On Thu, 08 Oct 2026 14:25:14 +0000, [email protected] wrote: > Hi > > On 2026-10-08 15:53, Matthieu Napoli wrote: > > Right, good point, I agree too, thanks! > > > > I opened a new PR that goes the other way around: > > https://github.com/php/php-src/pull/24192 > > > > I have also updated the RFC: > > https://wiki.php.net/rfc/single-binary-cli-fpm > > > > - `php` CLI is unchanged > > - `php-fpm` *always* includes `php` (and runs as CLI when run as `php` > > instead of `php-fpm`) > > - no need for a build option anymore > > - the diff is simpler > > - FPM aligns with FrankenPHP (both include the CLI) > > - No `--fpm` CLI option anymore, solves the objections raised > > previously in this thread > > > > That sounds much better indeed. > > I disagree that this is better from a discoverability and predictability > point of view and I also disagree with the concerns that the original > proposal would somehow “privilege” FPM. > > As for the first part: > > When running a PHP binary on the command line, my expectation is that > I'm running a CLI application and thus I expect to end up in the CLI > SAPI. Suddenly starting FPM, which potentially binds ports or sockets, > just because I happen to name the binary the wrong name (e.g. when using > a custom `p` symlink to run PHP after my distro switched to the > “combined binary” setup or just `php-8.7` that the RFC notes as running > FPM) would be very surprising. With the current proposal I also have no > way out, except naming the binary differently. Changing behavior based > on the binary name to do entirely different things is something that is > comparatively rarely used and thus folks are unlikely to be accustomed > to this being a thing (the most prominent example that comes to mind > would be Busybox). An explicit flag / argument would be properly > discoverable (appearing in help outputs) and would also be reliably > scriptable. > > For the second point, and tying into the first: PHP FPM is a / the > recommended solution of running PHP as a FastCGI application. Adding an > `--fpm` flag to the PHP binary to run PHP in “FastCGI mode” would match > the `-S` flag to run PHP in “HTTP mode” (which switches from the `cli` > to the `cli-server` SAPI). I understand that the current “HTTP mode” > implementation is meant to be used for development purposes only, but > that is an implementation detail. We could in theory implement a > production grade web server to PHP tomorrow (and potentially add > `--http` as the entrypoint for the “HTTP mode”, keeping `-S` as an > alias) and then we would have: > > php # CLI mode > php --fpm # FastCGI mode > php --http # HTTP mode > > with the `php` binary being the singular entrypoint for all use cases > where PHP is running “standalone” rather than embedded into something > else (as with mod_php). Alternatively, we use `--mode=fpm` to switch to > FPM mode instead of reserving the top level `--fpm` flag. > > Best regards > Tim Düsterhus
I agree with Tim here, for three reasons: - ergonomically, using `php --fpm <fpm-args>` is clearer than being forced to rename the binary (I only suggested that it's a possibility for build maintainers) - php-fpm usually lives in /usr/sbin which usually shouldn't be accessed directly by users - even if we ignore that, `php-fpm php-cli <cli-args>` is silly I don't share Larry's concern here, I don't see FrankenPHP completely replacing FPM any time soon. There has to remain a way to run php without locking ourselves to Go (and realistically Caddy). But even if it did, dropping a --fpm flag is no different than dropping a php-fpm target. (Since php --fpm, maybe php --http, or even php --le-monstre ;) are where it would end anyway, so I see no reason to gate it behind a dedicated --mode= flag) Kind regards Marc Henderkes
