This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients Drekin, eryksun, martin.panter, r.david.murray
Date 2015-08-28.19:30:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> If you dropped the isatty() check for stdout in Linux, you may 
> end up with the output of Readline in the file (assuming
> Readline is okay with this). The file would include all the
> cursor positioning codes, backspaces, etc, that Readline
> generates. But I haven’t actually tried this.

Yes, that's what happens. 

It seems to me the isatty check could be moved to call_readline in Modules/readline.c. This way PyOS_ReadlineFunctionPointer decides whether to call PyOS_StdioReadline. (See issue 512981 for the patch that introduced the isatty check.)

A related issue in Windows is that when stdout isn't a console, the text encoding defaults to the locale's ANSI encoding (e.g. cp1252). UTF-8 can be forced by setting the environment variable PYTHONIOENCODING=utf-8.

Also of concern is the pyreadline module. Its [Console class] assumes that the process standard handles are console handles. This is generally valid given the isatty check. OTOH, when I removed this check and redirected stdout to a file, pyreadline crashed in an endless loop. 

pyreadline's hook could punt to PyOS_StdioReadline if stdin and stdout don't both refer to the console. The problem there is calling the CRT's _fileno (POSIX) function in Python. Maybe the os module could wrap fileno in Modules/posixmodule.c. In addition to accepting a FILE pointer, os.fileno could accept an enum of C_STDIN, C_STDOUT, and C_STDERR.

Date User Action Args
2015-08-28 19:30:40eryksunsetrecipients: + eryksun, r.david.murray, martin.panter, Drekin
2015-08-28 19:30:40eryksunsetmessageid: <>
2015-08-28 19:30:40eryksunlinkissue24829 messages
2015-08-28 19:30:39eryksuncreate