[issue17647] subprocess.communicate() should preserve colored output on Windows

Caitlin Potter report at bugs.python.org
Sun Apr 7 22:02:58 CEST 2013


Caitlin Potter added the comment:

I'm not entirely positive that it would be doable, but looking at the
subprocess code, it looks like we do have an open handle to the windows
stdout buffer, including buffer attributes, so it should be possible to
translate coloured attributes into ANSI codes,

Whether this would or would not break anything else is a different story,
of course. Obviously there are times where you wouldn't want ANSI color
codes in the output, and I'm not sure how you could differentiate between a
pipe to a terminal buffer, or a pipe to a file.

Somewhat relevant, but perhaps not so much:
The google test framework does actually test isatty() before using ANSI
escape characters, however I've tested this same test program in a
development environment, with colours preserved, which was a bit curious
(the test I've put together is available at http://github.com/caitp/waftest,
however it will break on a lot of systems, depending on the way pthread
needs to be used)

On Sun, Apr 7, 2013 at 2:39 PM, Richard Oudkerk <report at bugs.python.org>wrote:

>
> Richard Oudkerk added the comment:
>
> On 07/04/2013 7:21pm, R. David Murray wrote:
> > Certainly on unix if you write ANSI color codes to stdout and the reader
> > doesn't strip them, they will be preserved and can be redisplayed, so
> > being able to do something similar on Windows would be nice.
>
> Although sensible unix programs capable of producing coloured text
> refuse to do so (by default) if output is a pipe rather than a tty.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue17647>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17647>
_______________________________________


More information about the Python-bugs-list mailing list