which it should be

hmm, it may should and it is on system configuration level, but for me it is unset since like always (?!) by default and the (default) variables_order then leads: EGPCS.

Given then that $_REQUEST only picks the GPC part from it, this is actually exactly as currently documented as all three are in.

So documentation won't need an update, right? Perhaps with the expectation management what default means?

PHP can't generally and reliably know when a variable is used to not, so the mechanism is as simple as it gets: if you put a variable into the expression then that variable gets bound.

Yes, but thinking not if the variable name is of a function parameter, then it either is an error if it is explicitly bound (use clause) or just the parameter (fn function).

using a named function is far more expressive and does not have such issues. the expected behaviour is by importing from the global variable table -- it is likely better to use an (optional) function parameter.

Nevertheless, named functions would make it much more backwards compatible back to the point when with PHP 5.0 __destruct() was introduced: https://3v4l.org/aO8IR

(we like the example).

looks good to me, git log --check ... does the standard git whitespace checks for the lines in the files of those revisions HEAD^..HEAD would be on the squash commit then as I understand it, so fine.

Additionally --check also looks for merge conflict markers which is sane, as you never want them in (and it once happened even here), just FYI, this one is for free.

And being late as review passed, some bits from looking at the changes:

• git diff --check -- does the same just on the changes. as the squash merge is already in the staging area (the cache), this would be git diff --check --cached.
• git -P diff --check --cached with no pager, no need to commit then.
• however if you need to do a commit but the user name/email is not configured, for a single commit, just prefix with the USER and EMAIL environment parameter, e.g. `USER=hk EMAIL="h@k" git commit -m "Squashed" - just FYI.

Presumably the issue is that the exception is being thrown in the child process except that PHP exits before the exception has a chance to bubble up. Which could be a good thing.

Yes, despite my first-hand expectation is the exception being seen thrown, I'd also say it's a good thing it's not thrown. This case is definitely pretty special and somewhat inverses the logic/intend of the registered error handler in the first place.

Perhaps it is worth to not bubble that into the error handler that was registered in the original process? IIRC PHP 7.4 didn't raise the warning and I see no obligation that PHP raises the warning as the process exit status is already 127 and PHP is not a shell, as in:

sh: 1: non-existent-command: not found

Not triggering the error handler also would have the benefit as it is effectively of no or only little use, or to replace an existing one, it would be just the default PHP error handling routine (e.g. standard diagnostic messages as configured, no callback to override).

Still though would be puzzling. In the documentation it is already written that there is no shell and it is directly executed. As we get a process handle, there must be child process thought, so perhaps that could be documented? @damianwadley

Description

The following code:

<?php declare(strict_types=1);

/*
 * PHP 8.0+ throw exception in error handler while proc_open executable not in path warning exit code 127 (shell/system)
 */
error_reporting(~0);

function error_handler($code, $message, $file, $line)
{
    fprintf(STDOUT, "error: %s ** and throw **\n", var_export(array_slice(func_get_args(), 0, 4), true));
    throw new ErrorException($message, 0, $code, $file, $line); // non-catchable non-fatal exception
}
set_error_handler('error_handler', ~0);

$pipes = [];
// command must be passed as array to trigger this, string won't work.
$process = proc_open(['non-existent-command'], [], $pipes);
// directly produce some output
fprintf(STDOUT, "open: %d\n", $process);
$status = proc_get_status($process);
ksort($status);
fprintf(STDOUT, "status: %s\n", json_encode($status));
// let proc finish
usleep(100000);
$status = proc_get_status($process);
ksort($status);
fprintf(STDOUT, "status: %s\n", json_encode($status));
$close = proc_close($process);
fprintf(STDOUT, "close: %s\n", var_export($close, true));

Resulted in this output:

open: 4
status: {"command":"non-existent-command","exitcode":-1,"pid":768535,"running":true,"signaled":false,"stopped":false,"stopsig":0,"termsig":0}
error: array (
  0 => 2,
  1 => 'proc_open(): Exec failed: No such file or directory',
  2 => '/home/mot/PhpstormProjects/make-and-compose/.cache/plain/scripts/procOpenThrow.php',
  3 => 17,
) ** and throw **
status: {"command":"non-existent-command","exitcode":127,"pid":768535,"running":false,"signaled":false,"stopped":false,"stopsig":0,"termsig":0}
close: -1

(exit status 0)

But I expected this output instead:

open: 4
status: {"command":"non-existent-command","exitcode":-1,"pid":768535,"running":true,"signaled":false,"stopped":false,"stopsig":0,"termsig":0}
PHP Fatal error:  Uncaught ErrorException: proc_open(): Exec failed: No such file or directory in script.php:17
Stack trace:
#0 {main}
  thrown in script.php on line 17

(exit status 255)

PHP Version

PHP 8.0.27 (cli) (built: Jan 13 2023 10:42:52) ( NTS )

Operating System

Ubuntu 20.04