docs(symfony-patterns): PHP_BINARY is empty under a non-CLI SAPI#76
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
github-actions
Bot
added
documentation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a new evaluation test case and documentation explaining how to safely spawn PHP subprocesses from non-CLI SAPIs using Symfony's PhpExecutableFinder instead of \PHP_BINARY. Feedback was provided on the documentation snippet to remove an undefined $args variable, which would cause a TypeError in PHP 8 when unpacked.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
d5b29e3 to
f3e86a6
Compare
Spawning a PHP subprocess with `new Process([\PHP_BINARY, ...])` works from a console command, cron or CI but throws "First element must contain a non-empty program name" under a web SAPI (Apache mod_php, PHP-FPM), where \PHP_BINARY is an empty string. The CLI paths that get tested pass; the web path fails only in production. Document resolving the interpreter via PhpExecutableFinder::find(false) — which returns \PHP_BINARY under CLI (no behaviour change) and falls through to PHP_BINDIR/php under a web SAPI — and add an eval covering the fix. Signed-off-by: Sebastian Mendel <info@sebastianmendel.de>
f3e86a6 to
64b28a9
Compare
|
What
\PHP_BINARYis an empty string under a non-CLI SAPI (Apachemod_php, PHP-FPM). It resolves to the interpreter path only under the CLI SAPI. Sonew Process([\PHP_BINARY, $script, ...])works from a console command, cron or CI, but throws under a web entry point:The trap: the CLI paths — the ones you test — pass, while the web path fails only in production.
Change
references/symfony-patterns.md: new section "Spawning a PHP subprocess (Processcomponent)" — resolve the binary viaPhpExecutableFinder::find(false)(returns\PHP_BINARYunder CLI, so console/cron/CI is unchanged; falls through toPHP_BINDIR/phpunder a web SAPI), handle thefalsereturn, never hardcode/usr/bin/php.evals/evals.json: evalphp-subprocess-from-web-sapicovering the fix.SKILL.md untouched (496 words). No version bump — content PR.
Origin
Field-hit:
composer/regenmoved its satis build to spawned subprocesses; CLical/cron/CI stayed green, the Apache-servedweb/hook.phpbroke immediately.