Re: Re: [PHP DEV] [Discussion] Native terminal helpers for PHP CLI

Hi it seems your replies don't contain proper in-reply-to or references headers, which breaks the threading. As an example in the archives at https://news-web.php.net/php.internals/132530 no other emails from the discussion are shown and https://news-web.php.net/php.internals/132528 only shows your email and my reply. On externals.io new threads are created for every email. Can you check the configuration of your email client and make sure to always use real “Reply” instead of sending a fresh email? On 2026-09-18 04:19, Pratik Bhujel wrote:

To answer your question regarding the domain problem: The primary issue is that PHP CLI currently lacks native primitives for non-canonical raw terminal mode and single keypress reading. Modern interactive CLI tools in userland (such as Laravel Prompts, Symfony Console, and interactive tools) want to deliver rich experiences like searchable selection menus, autocomplete, multi-choice checkboxes, spinners, and hidden password prompts.

Yes, I roughly understand the problem that is being solved. It's just something I never had to deal with, so I can't comment on whether the solution is complete and ergonomic.

2. Instance-based Terminal handle: Classes are no longer static wrappers. The Io\Terminal\Terminal class encapsulates a stream descriptor, created via named constructors stdin(), stdout(), stderr(), or by wrapping custom stream resources.

For consistency with the recently introduced APIs, the named constructors should start with a prefix that clearly indicates that the method is a constructor. As of now we have the following: - Dom\HTMLDocument::createEmpty(), ::createFromFile(), ::createFromString() - Time\Duration::fromSeconds(), ::fromMilliseconds(), …, ::fromIso8601DurationString() - Uri\Rfc3986\Uri::parse() (though this one also has a real constructor). For the Terminal I wonder why we need to have stdin, stdout, and stderr separately. For me logically a “Terminal” is a combination of all three and I would expect them to be “synchronized” if that makes sense?

3. Automatic RAII cleanup: Both Terminal instances and ModeToken objects track active raw mode and automatically restore terminal state upon destruction. If an uncaught exception terminates script execution, the destructor restores canonical mode so the developer shell is never left broken.

That makes sense to me.

5. Free-standing procedural functions: Io\Terminal provides procedural functions like is_tty(), read_key(), and get_size() for functional script usage.

I've taken another look at these and have some point that stood out to me: - Do we need all three of get_size(), get_width(), get_height()? The latter two seem redundant. - Should related methods have a common prefix for discoverability? So mode_enable_raw() and mode_restore() instead of enable_raw_mode() and restore_mode()? - Many (all?) of the functions also exists as methods on the Terminal class. This redundant procedural + object-oriented API design is something we no longer do. Decide on one of the two, depending on what is more useful. I expect the OO variant to be the right choice due to the RAII support. Best regards Tim Düsterhus