Debugging config problems with php --ini "hides" trailing whitespace

[schneems]

Description

Expected

Running php --ini with a problematic config will highlight the problem.

Actual

If you have a bad value for PHP_INI_SCAN_DIR (such as a trailing newline), it is hard to debug. The output looks like the newline is there for aesthetics when it's actually part of the config var.

Reproduction

This is how the output should look

$ php --ini
Configuration File (php.ini) Path: /opt/homebrew/etc/php/8.4
Loaded Configuration File:         /opt/homebrew/etc/php/8.4/php.ini
Scan for additional .ini files in: /opt/homebrew/etc/php/8.4/conf.d
Additional .ini files parsed:      /opt/homebrew/etc/php/8.4/conf.d/ext-opcache.ini

With bad env var:

$ export PHP_INI_SCAN_DIR="/opt/homebrew/etc/php/8.4/conf.d
"
$ php --ini
Configuration File (php.ini) Path: /opt/homebrew/etc/php/8.4
Loaded Configuration File:         /opt/homebrew/etc/php/8.4/php.ini
Scan for additional .ini files in: /opt/homebrew/etc/php/8.4/conf.d

Additional .ini files parsed:      (none)

Note how there are no "additional .ini files" parsed and there's an extra/stray newline.

Original SO issue https://stackoverflow.com/questions/79578288/why-does-php-not-find-ini-files-even-though-it-scanned-the-directory-theyre-in?noredirect=1#comment140342847_79578288. The person who responded has a "PHP gold badge" and 50K+ points. It wasn't immediately apparent to them that the whitespace shouldn't have been in the output.

Suggestions

Annotate empty/missing "scan for ..." directory

We could annotate the output to show if the directory exists:

$ export PHP_INI_SCAN_DIR="/opt/homebrew/etc/php/8.4/conf.d
"
$ php --ini
Configuration File (php.ini) Path: /opt/homebrew/etc/php/8.4
Loaded Configuration File:         /opt/homebrew/etc/php/8.4/php.ini
Scan for additional .ini files in: /opt/homebrew/etc/php/8.4/conf.d
 (does not exist)
Additional .ini files parsed:      (none)

Analysis: It still looks a little off, but at it's telling me that the folder does not exist. It would also be helpful for generic debugging (not involving a newline) like:

$ export PHP_INI_SCAN_DIR="/oops"
$ php --ini
Configuration File (php.ini) Path: /opt/homebrew/etc/php/8.4
Loaded Configuration File:         /opt/homebrew/etc/php/8.4/php.ini
Scan for additional .ini files in: /oops (does not exist)
Additional .ini files parsed:      (none)

Over time we could add different failure modes like (not a directory) if someone provides a file etc.

Wrap config output with characters

If we used a character like backtick to wrap values it would be more clear that the whitespace is a part of the value and not added for aestetics:

$ php --ini
Configuration File (php.ini) Path: `/opt/homebrew/etc/php/8.4`
Loaded Configuration File:         `/opt/homebrew/etc/php/8.4/php.ini`
Scan for additional .ini files in: `/opt/homebrew/etc/php/8.4/conf.d
`
Additional .ini files parsed:      (none)

Analysis: It's a little more subtle, but it's an improvement over the current state. It's likely not helpful for non-whitespace problems.

Why not both

We could do both:

$ php --ini
Configuration File (php.ini) Path: `/opt/homebrew/etc/php/8.4`
Loaded Configuration File:         `/opt/homebrew/etc/php/8.4/php.ini`
Scan for additional .ini files in: `/opt/homebrew/etc/php/8.4/conf.d
` (does not exist)
Additional .ini files parsed:      (none)

PHP Version

$ php -v
PHP 8.4.6 (cli) (built: Apr 8 2025 19:55:31) (NTS)
Copyright (c) The PHP Group
Built by Homebrew
Zend Engine v4.4.6, Copyright (c) Zend Technologies

Operating System

macOS 15

[SakiTakamachi]

I think this is not a bug. Admittedly, this is very misleading output, but it doesn't mean the functionality is broken.
I'll change the label to a feature request, maybe discussing this on the mailing list will get more feedback than in this thread.