Message125956
| Author |
davidsarah |
| Recipients |
David.Sankel, amaury.forgeotdarc, brian.curtin, christian.heimes, christoph, davidsarah, ezio.melotti, lemburg, mark, pitrou, ssbarnea, tim.golden, tzot, v+python, vstinner |
| Date |
2011年01月10日.23:38:43 |
| SpamBayes Score |
1.1757262e-13 |
| Marked as misclassified |
No |
| Message-id |
<1294702724.47.0.982623019962.issue1602@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
"... os.dup2() ..."
Good point, thanks.
It would work to change os.dup2 so that if its second argument is 0, 1, or 2, it calls _get_osfhandle to get the Windows handle for that fd, and then reruns the console-detection logic. That would even allow Unicode output to work after redirection to a different console.
Programs that directly called the CRT dup2 or SetStdHandle would bypass this. Can we consider such programs to be broken? Methinks a documentation patch for os.dup2 would be sufficient, something like:
"When fd1 refers to the standard input, output, or error handles (0, 1 and 2 respectively), this function also ensures that state associated with Python's initial sys.{stdin,stdout,stderr} streams is correctly updated if needed. It should therefore be used in preference to calling the C library's dup2, or similar APIs such as SetStdHandle on Windows." |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2011年01月10日 23:38:44 | davidsarah | set | recipients:
+ davidsarah, lemburg, tzot, amaury.forgeotdarc, pitrou, vstinner, christian.heimes, tim.golden, mark, christoph, ezio.melotti, v+python, ssbarnea, brian.curtin, David.Sankel |
| 2011年01月10日 23:38:44 | davidsarah | set | messageid: <1294702724.47.0.982623019962.issue1602@psf.upfronthosting.co.za> |
| 2011年01月10日 23:38:43 | davidsarah | link | issue1602 messages |
| 2011年01月10日 23:38:43 | davidsarah | create |
|