Stop any registry based autoexec commands from executing when shelling.

Running Windows CMD as Administrator puts you in C:\windows\system32.

If you have a registry entry of ...

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Command Processor]
"AutoRun"="@CD C:\\"

Causes all sorts of issues without the /D option.

From CMD /?

/D      Disable execution of AutoRun commands from registry

If /D was NOT specified on the command line, then when CMD.EXE starts, it
looks for the following REG_SZ/REG_EXPAND_SZ registry variables, and if
either or both are present, they are executed first.

    HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun

        and/or

    HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun

... (2.0 Backport)

• A working directory that does not exist does not work.
• Descriptors formatting.
• stream_set_blocking() takes integer not boolean as second parameter.
• Streams on Windows that didn't set to non-blocking should only fread() when there are bytes to read and only fclosed() while being eof. Fixes PHP Bug #51800. See Issue #3.

As of yet, a Process instance can't free memory. The built-in callback has a self-reference to the intance not cleared after instance destruction. I've tried to change both buildCallback and https://github.com/symfony/process/blob/v2.7.6/Process.php#L1373 usage to avoid self-referencing, but it can't be done without breaking BC, and the memory issue is still there.

A simple test script (that obiously can't be embedded in unit-tests)

$echo = function($inc){
    echo (memory_get_usage(true) / 1000000) . ' MB ' . $inc . PHP_EOL;
};
for ($inc = 0; $inc < 10000; $inc++) {
    $process = new Symfony\Component\Process\Process('echo 1');
    $process->mustRun();
    $process->stop();
    unset($process);

    $echo($inc);
}

Before:

1.572864 MB 0
5.505024 MB 9999

After:

1.572864 MB 0
1.572864 MB 9999

Ok, in this simple scenario 4 MB of RAM is nothing, but in our business app full of IOC where unset-ting is hard, our RAM explodes.

After stop(), the callback is no longer necessary.

Change PHP executable detection order to allow PHP_PATH environment variable usage and override PHP_BINARY detection behavior. Specifically when you need to use a different php.ini.

Due to php bug 51800, https://bugs.php.net/bug.php?id=51800, output from process must not use pipes. Both STDOUT and STDERR must be redirected to file.

Add the possibility to add a callback while waiting for the process to finish. This allows to add Logging or other actions.

class Example {

    private PsrLogger $logger;

    function runMyProcess() {
        $process->wait(
            null, 
            function (ProcessStatus $ProcessStatus): void {
                    $this->logger->debug(
                        'Running Render Videofile process with PID ' . $meltProcessStatus->getSymfonyProcess()->getPid()
                    );
            }
        );
    }
}

I created a quick Repo https://github.com/andrei0x309/tets_sym_proc to illustrate how this feature can be used, it essentially lets you run something even if your main script has terminated.

It is useful if you want to create something like new Process(['php', 'script_with_long_execution_time.php']); This was impossible to do on windows until the create_new_console flag was added in PHP 7.4.4. With this feature Process can be used like this:

// Start a process and detach form it on Win only
$process = new Process(['php', 'worker.php']);
$process->setWinOptions(["create_new_console" => true]); // New method I added
$process->disableOutput();
$process->start();

Process Class behavior will never change if the user doesn't use setWinOptions()

In addition to returning false, proc_open() triggers a warning when it fails. For example:

Warning: proc_open(): fork failed - Cannot allocate memory

When using the ErrorHandler, the warning gets promoted to an exception, and the next line, if (! is_resource(..., is not executed.

Executable finder should consider "executable" suffixes first on Windows because we basically ignore executability on Windows (line 80 below the change), which leads, for example, to finding usually-non-executable phpunit file first where both phpunit and phpunit.bat are present.

While 709e15e7a37cb7ed6199548dc70dc33168e6cb2d did not "cause" this problem, it made it more apparent (because the other is_executable() calls are wrapped in conditional logic that makes them less likely to be executed).

If PHP is configured with a non-empty open_basedir value that does not permit access to the target location, these calls to is_executable() throw warnings.

While Symfony may not raise exceptions for warnings in production environments, other frameworks (such as Laravel) do, in which case any of these checks causes a show-stopping 500 error.

We fixed a similar issue in the ExecutableFinder class via https://github.com/symfony/symfony/pull/16182 .

If PHP is configured with a non-empty open_basedir value that does not allow access to the target location, these calls to is_executable() throw warnings. While Symfony may raise exceptions for warnings in production environments, other frameworks (such as Laravel) do, in which case any of these checks causes a show-stopping 500 error.