Context: When reviewing BC issues as part of my 8.5. RM duties I came across #18527 and the follow ups.

As this change breaks existing scripts we should document it and give people alternatives, or revert it. I will sync with @DanielEScherzer on that and gather some feedback.

The introduced inconsistentcy between php --ini, php -i, php-config --ini and php -r 'echo php_ini_loaded_file();' isn't great either.

And while this PR would "fix" the BC issue, I'm against changing the output depending on tty/no-tty as that's another source of non-obvious behavior and confusion.

Yeah, I'm also not a big fan of having different output for TTY and not - when I build up a set of piped commands I inspect the output from one and then write the next, so having a different output when I run the command directly and when the output is piped somewhere would be confusing

We can tighten the search a bit to skip php --ini=..., forks, archived repos, and documentation pages:

content:/php --ini(\s|$|['"`])/ -is:fork -is:archived -path:.md -path:.rst -path:.html -path:.txt

only 1.5k hits now

Would it be a break to add something like php --ini --no-quotes where another option controls the quoting?

I'm against changing the output depending on tty/no-tty as that's another source of non-obvious behavior and confusion.

That's fair. I agree it's a bit mind-bendy to introduce a bug in a script that might only exist while you're not looking at it.

Would it be a break to add something like php --ini --no-quotes where another option controls the quoting?

I think the best long-term option is something like this rubygems/rubygems#8728 where the output is in an explicitly machine readable format (--format=json in that case). So then anyone doing scripting has a stable interface and the maintainers of the CLI code don't have to guess based on other ancillary signals (like TTY or not). It depends on the existence of a tool like jq to parse but that's fairly common at this point (my opinion).

But that's a much bigger lift to introduce a new JSON output and associated formatting flag. I'm not confident I could make an acceptable patch to get a feature like that over the line (C is not my day-job lang).

(brainstorming) If there's interest there we could put out a "help wanted" call. In the mean time if there's some desire to allow for a switch of this behavior we could introduce --format=noquote (or some other, better value) and while we wait for an eventual --format=json

Thank you for the quick reply, especially considering the long waiting time. Much appreciated.

Regarding the whole feature: After reaching out to a couple more people nobody else seemed all that concerned with the BC implications of this change. Given that, I'm not going to argue for removing this from 8.5. If anything we'll document it in UPGRADING and suggest a better way of getting that data.

Adding --format=json or maybe --ini=json is something others also suggested as a stable computational API outside of php -r 'echo php_ini_loaded_file();' and `php -r 'echo ini_get("extension_dir");'. This addition likely doesn't even require an RFC. I'm happy to help with that as well, should be rather simple as json_encode is always available since PHP 8.0.

So if nobody objects I'd close this one.

Closing in favor of #19655