Edit report at https://bugs.php.net/bug.php?id=72768&edit=1
ID: 72768
Comment by: mlocati at gmail dot com
Reported by: mlocati at gmail dot com
Summary: Add ENABLE_VIRTUAL_TERMINAL_PROCESSING flag for
php.exe
Status: Analyzed
Type: Feature/Change Request
Package: Output Control
Operating System: Windows 10
PHP Version: Irrelevant
Block user comment: N
Private report: N
New Comment:
I tried to add this new function, and since this is my first attempt to contribute to PHP I'm
surely doing something wrong: the compilation fails with strange messages (redefinitions of #define,
structs, functions).
Previous Comments:
------------------------------------------------------------------------
[2016-08-22 09:34:47] ab@php.net
@mlocati, I only mentioned the control sequences stripping as a result of further deliberation. Bash
does it, as you mentioned. ASCII (compatible) would be probably easy to do, but not sure with double
byte and other mb encodings. So mentioned it, just to keep in mind, this option is possible.
Otherwise - yeah, what we discuss till now as an initial plan is to not to strip control sequences
automatically.
Thanks.
------------------------------------------------------------------------
[2016-08-22 07:02:37] mlocati at gmail dot com
@ab I don't fully understand the point about stripping the control sequences...
Given that
1. PHP developers have a way to know if STDOUT/STDERR support control sequences (#72768)
2. PHP developers have a way to know if STDOUT/STDERR are not redirected to a file (#72896)
they may decide to send the control sequences or not.
On the other hand, even if the PHP developers know that the output does not support control
sequences, they may need to output them. I don't see a reason why they would want to do that,
but I think developers should be as free as they want.
Furthermore, stripping out chars could be risky and requires a deep study.
------------------------------------------------------------------------
[2016-08-21 22:41:50] ab@php.net
@mlocati, amazing work, thanks! Your code can already be used as base framework to support the PHP
integration.
The issue with a new ini is, that there are already quite a few. That's the reason it's
preferable to not to introduce a new one, especially if it's solvable another way. Regarding
streams, my thought was like piece of code below:
$fd = fopen("php://stdout", "r");
stream_context_set_option($fd, "stdio", "vt100_enabled", true);
fwrite($fd, "\033[101;93m Yellow text on red background \033[0m\n");
fclose($fd);
Same with php/stdin, etc. Any such stream is an isolated version of the original system descriptor,
it won't affect all the output. OFC in fact, it might have to be a singleton, as it's only
one I/O device at the end. But, as a stream is buffered, the decision whether to out/read the
control sequences can be deferred.It could be cool ofc, to be able doing the same with the std I/O
constants, fe like
stream_context_set_option(STDOUT, "stdio", "vt100_enabled", true);
but i'm not sure it can work exactly that way, but need to double check. Still, it could be an
additional user land stream function to deliver the terminal info or switch to the required mode.
Maybe a function were even more universal in that case, like stream_vt100_supported(STDOUT), etc.
As it looks like after thinking a bit more, stripping the control sequences might be relatively
easy. Should research more yet, but the sequences i've seen follow a particular pattern.
Especially in the case of the direct I/O, one could just scroll over them. Even with the buffered
stream, that might be not a big overhead. So probably shouldn't completely abandon that option.
Another nice thing in streams could be a stream filter, which could be used for this task.
The point with the mb encodings - I'd not write it off yet. We'll have to test and do some
adjustments under circumstances. Fe for xterm, there are several dedicated versions for Asian
encodings, the question is just why.
One point with your latest test code - to check were whether it'd fail for a non standard
terminal. There are nice alternative terminals like ConEmu, which already provide the functionality
even on lower Windows versions. I'm not sure yet, how to solve this without checking any
possible APIs. This would probably prevent the automation in some case, but is probably an overhead
ATM and can be checked at some later stage. It's ATM only about the standard cmd.exe, anyway.
It is already a very good start. If you've mood and time, you could already begin the PHP
patch. Maybe you've a better idea how to integrate it with PHP, please let me know. Writing the
tests for the prospective usage, then matching with internals to correct/improve the actual
implementation might be next step.
Thanks.
------------------------------------------------------------------------
[2016-08-19 08:27:02] mlocati at gmail dot com
Strictly related to this issue: https://bugs.php.net/bug.php?id=72896
------------------------------------------------------------------------
[2016-08-18 15:10:06] mlocati at gmail dot com
@ab
I fully understand that PHP scripts that output control codes on older systems (or when the
ENABLE_VIRTUAL_TERMINAL_PROCESSING flag is not set for the current process) is really bad.
That's why I suggested to use ini_get/ini_set.
For instance, if the key used to control if the system has color support is 'win_vt100', a
script could do something like this:
<php
ini_set('win_vt100', true); // returns true on success, false on failure
if (ini_get('win_vt100')) {
// print with ANSI control codes
} else {
// print without ANSI control codes
}
?>
About potential problems with the multibyte encodings: I think it's cmd.exe that takes care of
it. BTW, to solve any problem and to be backward compatibile, vt100 could be disabled by default,
and enabled only by the scripts that wants it.
By using the ini_get/ini_set approach, people that wants ANSI codes enabled by default could set its
value to true in their php.ini file.
PS: I created a gist with a sample C code that implements the following functions:
- check if the current console may have has colors
- determine if the current console has colors
- enable/disable color support for the current console
You can find it here: https://gist.github.com/mlocati/21a9233ac83f7d3d7837535bc109b3b7
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=72768
--
Edit this bug report at https://bugs.php.net/bug.php?id=72768&edit=1