Eryk Sun added the comment:
> When there is no console, stdio should use the default textio
> encoding that is ANSI for now.
stdin, stdout, and stderr are special and can be special cased because they're
used implicitly for IPC. They've always been acknowledged as special by the
existence
Inada Naoki added the comment:
> Okay, and also when GetConsoleCP() fails because there's no console (e.g.
> python.exe w/ DETACHED_PROCESS creation flag, or pythonw.exe).
When there is no console, stdio should use the default textio encoding that is
ANSI for now.
> However, using UTF-8
Eryk Sun added the comment:
> How about treating only UTF-8 and leave legacy environment as-is?
> * When GetConsoleCP() returns CP_UTF8, use UTF-8 for stdin.
> Otherwise, use ANSI.
Okay, and also when GetConsoleCP() fails because there's no console (e.g.
python.exe w/ DETACHED_PROCESS
Inada Naoki added the comment:
I think using Console codepage for stdio is better. But I am afraid about
breaking existing code.
How about treating only UTF-8 and leave legacy environment as-is?
* When GetConsoleCP() returns CP_UTF8, use UTF-8 for stdin. Otherwise, use ANSI.
* When
Eryk Sun added the comment:
> I understand Python should be using reading the current CP (from
> GetConsoleOutputCP
> or using the default OEM CP, and not assuming ANSI CP for stdio
A while ago I analyzed text encodings used by many of the legacy CLI programs
in Windows. Some programs hard
Alexey Izbyshev added the comment:
> I've been struggling to understand today why a simple file redirection
> couldn't work properly today (encoding issues)
The core issue is that "working properly" is not defined in general when we're
talking about piping/redirection, as opposed to the
New submission from Alexandre :
Hello,
first of all, I hope this was not already discussed (I searched the bugs but it
might have been discussed elsewhere) and it's really a bug.
I've been struggling to understand today why a simple file redirection couldn't
work properly today (encoding
