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.

classification
Title: curses.initscr - initscr exit w/o env(TERM) set
Type: Stage:
Components: Library (Lib) Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: akuchling Nosy List: akuchling, jrlilly, mwh
Priority: normal Keywords:

Created on 2005-02-09 14:51 by jrlilly, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
initscr.patch jrlilly, 2005-02-09 19:49 short patch for the problem
initscr-counter-patch.diff mwh, 2005-02-10 11:22 mwh's fix #1
initscr-counter-patch-2.diff mwh, 2005-06-13 18:13 mwh fix #2
Messages (11)
msg24207 - (view) Author: Jacob Lilly (jrlilly) Date: 2005-02-09 14:51
the initscr in ncurses will cause an immeadiation exit
if the env doesn't have the TERM variable set.  Could
the curses.initscr be changed so it tests if TERM is
set and raises an exception?  It would be helpful to be
able to try and except this instead of just having
ncurses exit for you.
msg24208 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2005-02-09 18:45
Logged In: YES 
user_id=6656

How amazingly terrible (on ncurses part).  Do you want to/are you able 
to work on a patch?
msg24209 - (view) Author: Jacob Lilly (jrlilly) Date: 2005-02-09 19:49
Logged In: YES 
user_id=774886

sorry, I should have done that in the beginning; I have it
raising a RuntimeError, I think thats what it is.  This
doesn't really solve the problem in whole, since ncurses
initscr has lots of ways it could decide to decide to exit
(any return value from newterm causes it to exit), but it
does solve a more common one.  Anything else would require
modifying ncruses to be responsible.
msg24210 - (view) Author: Jacob Lilly (jrlilly) Date: 2005-02-09 19:51
Logged In: YES 
user_id=774886

that is any return of 0 from newterm
msg24211 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2005-02-09 23:19
Logged In: YES 
user_id=6656

Yeah, I noticed that.  We could at least call setupterm(0, NULL) first, I 
guess...
msg24212 - (view) Author: Jacob Lilly (jrlilly) Date: 2005-02-10 00:06
Logged In: YES 
user_id=774886

if you pass setupterm 0 for the term name it just tries to
get the env variable, so the env test should cover it pretty
well.  It might make more sense to check the env first and
then pass "unkown", setuperm("unknown", -1).  This would
seem to match the path that curses initscr follows.  This
would also raise _curses and curses shared exception.
msg24213 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2005-02-10 11:22
Logged In: YES 
user_id=6656

The motivation for calling setupterm() ourselves was that I noticed

TERM=garbage python -c 'import curses; curses.initscr()'

hit the irritating error path too.  I also hadn't realised there was a 
version of initscr in curses/__init__.py, which makes things easier... how 
about the attached?
msg24214 - (view) Author: Jacob Lilly (jrlilly) Date: 2005-02-10 13:41
Logged In: YES 
user_id=774886

The only thing that worries me about that is it takes a
different path than ncurses does (or at least 5.4 does).  If
the env variable isn't set, initscr in ncurses assumes the
term type is "unknown" (if no env) and passes "unknown"
along, whereas setupterm assumes that if you pass it NULL
for the term and the env isn't set, then it simply returns
0.  I doubt anyone will have a valid term setup for unknown,
but who knows.  Beyound that works for me.  BTW, the gnu
ncurses guys say this is the the behavior in the standard.
msg24215 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2005-06-13 18:13
Logged In: YES 
user_id=6656

How about the attached, then?

(sorry for the long, long wait)
msg24216 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2007-01-05 14:36
Patch #2 looks OK.  Any objections if I just commit it (to trunk only)?
msg62755 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2008-02-23 15:49
Patch #2 applied to 2.6-trunk in rev. 60989.
History
Date User Action Args
2022-04-11 14:56:09adminsetgithub: 41552
2008-02-23 15:49:54akuchlingsetstatus: open -> closed
resolution: fixed
messages: + msg62755
2008-01-21 13:50:56akuchlingsetassignee: mwh -> akuchling
2005-02-09 14:51:06jrlillycreate