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.

Title: Curses sometimes fails to initialize terminal
Type: behavior Stage:
Components: Extension Modules Versions: Python 2.5
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: akuchling, fer_perez, terry.reedy
Priority: normal Keywords:

Created on 2008-04-18 22:51 by fer_perez, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit fer_perez, 2008-04-18 22:51 Simple test to see if the bug is present (it can't cause it though)
Messages (4)
msg65626 - (view) Author: Fernando Pérez (fer_perez) Date: 2008-04-18 22:51
Curses sometimes fails to correctly initialize the terminal. 
Unfortunately I don't know how to reproduce the problem, it was reported
multiple times by ipython users, but I have no idea what causes it.  I
finally found a workaround by making a termios call that at least
restores terminal state (see attachment), but it's just a workaround,
not a real fix.

The issue manifests itself as follows: at some point (I don't know why),
a call to curses.initscr() doesn't actually set the terminal in the
usual mode where input isn't accepted, but instead the terminal
continues accepting normal input, issuing newlines, etc.  The only sign
that curses is active is that in a modern terminal, the scrollbar
changes to fill the screen.  After this, calling curses.endwin(),
instead of restoring terminal state, leaves the terminal in the mode
that typically initscr() would put it in: no input is displayed,
printouts swallow end-of-line characters, etc.

When this happened in ipython sessions, we'd just suggest users call
!reset (the system command), which would restore terminal state.  But
the problem is obviously in curses itself, because once this problem
appeared, running the attached script would always print 'False' for the
state condition checked there.

For now in IPython we have a workaround, but perhaps with this little
description/example, someone who knows the curses code might be able to
actually fix the real problem.  If I find a reliable way to trigger the
bug, I'll add comments here indicating so.
msg67898 - (view) Author: Fernando Pérez (fer_perez) Date: 2008-06-10 07:08
As reported by Ondrej Certik on the IPython mailing list:

Here is how to reliably (100%) reproduce it in ipython 0.8.2 (the bug
indeed goes away in 0.8.4):

together with a screenshot how the terminal looks like (see the
comment #6 for the exact sympy revision to use). Maybe you could use
it to track the bug down in curses, as your patch only seems to be a
workaround (albeit working).



While unfortunately right now I don't have the time to try and whittle
this down to a smaller, self-contained example, it's great to at least
have a guaranteed reproducible way of triggering the bug.  It requires
installing specific versions of both ipython and sympy, but that's very
straightforward to do, as both are pure-python projects with no
dependencies outside the stdlib.
msg107431 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-06-09 22:37
Is this an issue with 2.7 or 3.1?
msg121080 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-11-12 21:13
That should be, for 2.7 or 3.2, as 3.1 is nearly finished.
Date User Action Args
2022-04-11 14:56:33adminsetgithub: 46909
2011-03-30 21:03:58terry.reedysetstatus: pending -> closed
resolution: out of date
2010-11-12 21:13:30terry.reedysetstatus: open -> pending

messages: + msg121080
2010-11-12 20:56:07akuchlingsetstatus: pending -> open
assignee: akuchling ->
2010-06-09 22:37:23terry.reedysetstatus: open -> pending
nosy: + terry.reedy
messages: + msg107431

2008-06-10 07:08:56fer_perezsetmessages: + msg67898
2008-04-25 18:08:31akuchlingsetassignee: akuchling
nosy: + akuchling
title: curses -> Curses sometimes fails to initialize terminal
2008-04-18 22:51:07fer_perezcreate