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.

Unsupported provider

classification
Title: Messed up terminal after calling curses.initscr() twice.
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.1, Python 3.2, Python 2.7, Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Sami.Zerrade, Sreejith.Madhavan, barry, doko, ferringb, serhiy.storchaka, yury
Priority: normal Keywords: needs review, patch

Created on 2009-12-23 01:46 by yury, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
setupterm.patch Sami.Zerrade, 2010-01-30 11:37 Modifies _cursesmodule.c to only call setupterm if initscr() hasn't been called
Messages (8)
msg96826 - (view) Author: Yury (yury) Date: 2009-12-23 01:46
Calling curses.initscr after curses.endwin() results in a messed up
terminal the second time curses.endwind() is called. For example:

import curses
curses.initscr(); curses.endwin(); curses.initscr(); curses.endwin()

This behaves correctly in python 2.5. It does not work in python 2.6.
msg98559 - (view) Author: Sami Zerrade (Sami.Zerrade) Date: 2010-01-30 10:38
This is being caused by the following 2 new lines in the initscr() function of Lib/curses/__init__.py:


setupterm(term=_os.environ.get("TERM", "unknown"),
            fd=_sys.__stdout__.fileno())

Commenting them out will cause the behavior from version 2.5.  


In general, invoking the C curses library's setupterm() function after the C initscr() function has been called will cause the terminal to break the next time that endwin() is called.  In this particular case, the first call to the Python initscr() function provides the call to the C initscr() and the second call to Python's initscr() provides the call to setupterm().  The bug can be fixed by having the Python initscr() function in __init__.py make sure that initscr hasn't been called before making the call to setupterm().
msg98560 - (view) Author: Sami Zerrade (Sami.Zerrade) Date: 2010-01-30 11:27
I'm attaching a file that patches Modules/_cursesmodule.c to make sure that initscr hasn't been called before invoking setupterm().  This fixes the bug for me; your mileage may vary.
msg103990 - (view) Author: Sreejith Madhavan (Sreejith.Madhavan) Date: 2010-04-23 07:27
Thanks for the patch.
I can confirm that the patch works for 64bit builds of python-2.6.5 on Solaris (amd64 and sparc) and RHEL5 amd64. The curses library used was ncurses-5.7 with widechar support.
msg111599 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2010-07-26 08:04
shouldn't `initialised_setupterm' be tested instead?
msg112106 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2010-07-30 21:42
committed in r83306 (2.7) and r83307 (3.2); verified that the behaviour in offlineimap (reported in http://bugs.debian.org/586433 is fixed).
will apply it to 2.6 and 3.1 after a few days.
msg112995 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2010-08-05 16:22
Doko asks in IRC to apply this for 2.6.6.  Approved.
msg113216 - (view) Author: Ferringb (ferringb) * Date: 2010-08-07 22:53
This change isn't hugely friendly API wise- for code that invokes setupterm() multiple items (and does so knowing what it's doing), they're now silently locked into whatever the first term invocation was.

Personally, an override here has major usage- especially for scenarios were people are writing tests and adjusting the term's they're using to check their implementation.

As it is now, they wind up locked into whatever term they first invoked it with, getting back term codes from tigetstr for the previous term...
History
Date User Action Args
2022-04-11 14:56:55adminsetgithub: 51816
2016-04-23 01:46:30berker.peksagsetstatus: open -> closed
stage: test needed -> resolved
2014-12-02 13:45:46serhiy.storchakasetnosy: + serhiy.storchaka
2010-08-07 22:53:48ferringbsetnosy: + ferringb
messages: + msg113216
2010-08-05 16:22:26barrysetstatus: pending -> open
nosy: + barry
messages: + msg112995

2010-07-30 21:42:20dokosetstatus: open -> pending
resolution: fixed
messages: + msg112106

versions: + Python 3.1, Python 2.7, Python 3.2
2010-07-26 08:04:03dokosetnosy: + doko
messages: + msg111599
2010-04-23 07:27:31Sreejith.Madhavansetnosy: + Sreejith.Madhavan
messages: + msg103990
2010-01-30 16:33:02brian.curtinsetpriority: normal
keywords: + needs review
type: behavior
stage: test needed
2010-01-30 11:37:52Sami.Zerradesetfiles: + setupterm.patch
2010-01-30 11:35:22Sami.Zerradesetfiles: - setupterm.patch
2010-01-30 11:27:12Sami.Zerradesetfiles: + setupterm.patch
keywords: + patch
messages: + msg98560
2010-01-30 10:38:35Sami.Zerradesetnosy: + Sami.Zerrade
messages: + msg98559
2009-12-23 01:46:16yurycreate