This functionality didn't actually work.
This was discussed on the mailing list [1] and no one objected.
[1] https://externals.io/message/126368
Closes GH-17883.
* Show build provider information in "php -v"
Vendors such as distributions can set the `PHP_BUILD_PROVIDER`
variable, that gets printed in phpinfo. However, I find that users check
`php -v` more often than phpinfo to see what PHP they're running. The
problem with this is that it does not show that build provider
information.
This change makes the build provider information printed on an
additional line of the version information.
* Put on same line so it works with or without env var
Unbreaks build without PHP_BUILD_PROVIDER set.
* change wording in provider version text
better grammatically; many different possibilities here though
* Unify SAPI version printing
This makes it so that all of the SAPIs share the same code for printing
version information. This is useful in case of any future changes to the
version information, such as i.e. adding build provider to the output.
* Make include for php_print_version explicit
* Preserve phpdbg version and output channel
php_printf doesn't have same semantics, as phpdbg_out could be on a
different output than stdout/err. Also add the phpdbg version (in case
it differs from PHP's, to keep similar output before this PR)
* remove size variables
we don't use them and CI doesn't like unused variables
* Fix format string insecurity
This syncs few inconsistencies between the Windows and Autotools build
systems:
- HAVE_OPENSSL_EXT is now defined in the same style on both systems
(undefined - extension is not available, defined to 1 - extension is
available)
- HAVE_OPENSSL removed as it was only defined on Windows
* Remove tautologically false condition in php_cli.c
* Make the CLI mode available via the SAPI globals
When hooking into RINIT it is currently pretty much impossible to determine
whether a file will actually be executed or if it just will be linted,
highlighted, or comments stripped: The startup is identical for all of them and
the chosen mode is not currently exposed to other extensions.
The `SG(server_context)` is currently entirely unused for the `cli` SAPI. It
appears to be appropriate to store the mode as a SAPI-specific information
inside of it.
* Mark many functions as static
Multiple functions are missing the static qualifier.
* remove unused struct sigactions
struct sigaction act, old_term, old_quit, old_int;
all unused.
* optimizer: minXOR and maxXOR are unused
This is supported in both the CLI and CGI modes. For CLI this required
little changes.
For CGI, the tricky part was that the options parsing happens inside the
loop. This means that options passed after the -l flag were previously
simply ignored. As we now re-enter the loop we would parse the options
again, and if they are handled but don't set the script name, then CGI
will think you want to read from standard in. To keep the same "don't
parse options" behaviour I simply wrapped the options handling inside an
if.
Closes GH-10024.
Closes GH-10710.
When writing the output in the CLI is interrupted by a signal, the
writing will fail in sapi_cli_single_write(), causing an exit later in
sapi_cli_ub_write(). This was the other part of the issue in GH-11498.
The solution is to restart the write if an EINTR has been observed.
Closes GH-11510.
I grepped for php_printf cases in main/ and sapi/ and converted the
cases which clearly indicate errors to fprintf(stderr, ...), like
suggested in the linked issue.
Closes GH-11163.
I found no reason why this is done this way.
Of course this will allow users to do stupid stuff like
`fclose(STDOUT);` etc. but if they type in that code they clearly know
what they're doing...
Close GH-11169.
* PHP-8.1:
[ci skip] NEWS
Fix GH-8952: std streams can not be deliberately closed (#8953)
intl extension, build fix for icu >= 69.x release. ubrk/ucnv_safeClone had been deprecated in favor of ubrk/ucnv_clone which does not use user provided stacks but remain thread safe.
We revert the commits which caused this regression from the PHP-8.0 and
PHP-8.1 branches for now. We keep it in "master" because of PR #8833
which may offer a proper fix without BC break.
Extensions may (and do) write to stderr in mshutdown and similar. In
the best case, with the stderr stream closed, it's just swallowed.
However, some libraries will do things like try to detect color, and
these will outright fail and cause an error path to be taken.
Extensions may (and do) write to stderr in mshutdown and similar. In
the best case, with the stderr stream closed, it's just swallowed.
However, some libraries will do things like try to detect color, and
these will outright fail and cause an error path to be taken.
Extensions may (and do) write to stderr in mshutdown and similar. In
the best case, with the stderr stream closed, it's just swallowed.
However, some libraries will do things like try to detect color, and
these will outright fail and cause an error path to be taken.
