sapi/cli: Extend --ini to print INI settings changed from the builtin default

[TimWolla]

This is intended to make it easier to check whether or not a given INI setting is changed from the default when building reproducers for a bugreport, without forgetting any that might be relevant to the report.

As an example, running sapi/cli/php -c /etc/php/8.3/cli/ --ini on my Ubuntu will now output:

Configuration File (php.ini) Path: /usr/local/lib
Loaded Configuration File:         /etc/php/8.3/cli/php.ini
Scan for additional .ini files in: (none)
Additional .ini files parsed:      (none)

Non-standard INI settings:
allow_url_include: "0" -> ""
auto_append_file: (none) -> ""
auto_prepend_file: (none) -> ""
display_errors: "1" -> ""
display_startup_errors: "1" -> ""
enable_dl: "1" -> ""
error_reporting: (none) -> "22527"
html_errors: "1" -> "0"
ignore_repeated_errors: "0" -> ""
ignore_repeated_source: "0" -> ""
implicit_flush: "0" -> "1"
log_errors: "0" -> "1"
mail.add_x_header: "0" -> ""
mail.mixed_lf_and_crlf: "0" -> ""
max_execution_time: "30" -> "0"
memory_limit: "128M" -> "-1"
request_order: (none) -> "GP"
session.cookie_httponly: "0" -> ""
session.gc_divisor: "100" -> "1000"
session.gc_probability: "1" -> "0"
session.sid_bits_per_character: "4" -> "5"
session.sid_length: "32" -> "26"
short_open_tag: "1" -> ""
unserialize_callback_func: (none) -> ""
user_dir: (none) -> ""
variables_order: "EGPCS" -> "GPCS"
zend.assertions: "1" -> "-1"
zend.exception_ignore_args: "0" -> "1"
zend.exception_string_param_max_len: "15" -> "0"

[cmb69]

Looks like a good idea, although it might be confusing, since distros may ship non-default settings as default, so users might wonder why they have some non-default settings. Maybe only show the non-defaults when explicitly requested (maybe --ini=diff or something)?

[TimWolla]

Maybe only show the non-defaults when explicitly requested (maybe --ini=diff or something)?

That would also work for me, no strong opinion (other than that this should be a thing one way or another). My intention with this PR was to spark this kind of discussion and feedback 😄

[NattyNarwhal]

Looks like a good idea, although it might be confusing, since distros may ship non-default settings as default, so users might wonder why they have some non-default settings. Maybe only show the non-defaults when explicitly requested (maybe --ini=diff or something)?

As a downstream distributor, this is something to keep in mind. This feature looks pretty useful at first glance for triaging issues users have, although we'd have to keep in mind our own defaults when they show up in the output (which themselves are derived from php.ini-production).

[TimWolla]

although we'd have to keep in mind our own defaults when they show up in the output (which themselves are derived from php.ini-production).

Indeed. I do not expect this to be a big issue in practice, because most settings won't meaningfully affect the behavior of a PHP script. It would perhaps be a good opportunity to check whether the php.ini-production settings could be aligned with the builtin defaults one way or another.

I expect this to be most useful for the OPcache INIs and possibly extensions with a large number of settings where the user is expected to modify them (e.g. Xdebug).

[Girgias]

Minor remark, but MSTM.

[TimWolla]

@cmb69 Do you have a strong opinion about the flag to use or is this good to you?

[cmb69]

No strong opinion; just using --ini is okay for me.

[TimWolla]

Thank you. I'll merge this PR as-is next week (after adding NEWS / UPGRADING). Then there's roughly 7 months until feature freeze for any other changes to make 😃

[bukka]

Sorry I somehow missed it. Last time I checked there was that --ini=diff so I thought that there was an agreement on that but somehow it didn't get implemented.

So I'm not sure if it's a good idea to extend the current function as there might be scripts relaying on the current limited output. Also I wouldn't really care about the diff if I wanted to see just configuration files. I really liked more that diff suggestion though.

[TimWolla]

@bukka Thank you for the feedback. I've just sent an email to Internals, pointing folks towards this PR for some additional opinions.