Nadeem Vawda added the comment:
> Nadeem: is the failure you show in msg141798 with a version of test_curses
> that uses pty.openpty?
Yes, I tried the following change:
--- a/Lib/test/test_curses.py
+++ b/Lib/test/test_curses.py
@@ -328,11 +328,12 @@
curses.resetty()
def test_main():
- if not sys.__stdout__.isatty():
- raise unittest.SkipTest("sys.__stdout__ is not a tty")
# testing setupterm() inside initscr/endwin
# causes terminal breakage
- curses.setupterm(fd=sys.__stdout__.fileno())
+ #curses.setupterm(fd=sys.__stdout__.fileno())
+ import pty
+ _, pty = pty.openpty()
+ curses.setupterm(fd=pty)
try:
stdscr = curses.initscr()
main(stdscr)
(I've never used openpty, either in Python or in C, so I can't vouch for
the correctness of this usage.)
> If it isn't: I'd expect more test failures on buildbot machines where the
> buildbot agent is started as a system daemon, in which case the process
> doesn't have a tty at all. Using pty.openpty it would be possible to ensure
> that there is a pty that can be used for the test.
Looking at the actual buildbot results, most of the *nix bots I checked
are actually skipping this test; the only one I could find that wasn't is
the "x86 Ubuntu Shared" bot:
ttp://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/6640/steps/test/logs/stdio
So it looks like on most of the bots, buildbot is running without a tty.
Then, test_main() sees that sys.__stdout__ isn't suitable to run the
test, and bails out.
It'd be great if you can come up with a fix that gets the test running
in this environment, but it'll probably be more complicated than just
slotting in a call to openpty().
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12669>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
