Bugs item #1119331, was opened at 2005-02-09 09:51
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jacob Lilly (jrlilly)
Assigned to: Michael Hudson (mwh)
Summary: curses.initscr - initscr exit w/o env(TERM) set
Initial Comment:
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.
----------------------------------------------------------------------
>Comment By: A.M. Kuchling (akuchling)
Date: 2007-01-05 09:36
Message:
Logged In: YES
user_id=11375
Originator: NO
Patch #2 looks OK. Any objections if I just commit it (to trunk only)?
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2005-06-13 14:13
Message:
Logged In: YES
user_id=6656
How about the attached, then?
(sorry for the long, long wait)
----------------------------------------------------------------------
Comment By: Jacob Lilly (jrlilly)
Date: 2005-02-10 08:41
Message:
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.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2005-02-10 06:22
Message:
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?
----------------------------------------------------------------------
Comment By: Jacob Lilly (jrlilly)
Date: 2005-02-09 19:06
Message:
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.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2005-02-09 18:19
Message:
Logged In: YES
user_id=6656
Yeah, I noticed that. We could at least call setupterm(0, NULL) first, I
guess...
----------------------------------------------------------------------
Comment By: Jacob Lilly (jrlilly)
Date: 2005-02-09 14:51
Message:
Logged In: YES
user_id=774886
that is any return of 0 from newterm
----------------------------------------------------------------------
Comment By: Jacob Lilly (jrlilly)
Date: 2005-02-09 14:49
Message:
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.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2005-02-09 13:45
Message:
Logged In: YES
user_id=6656
How amazingly terrible (on ncurses part). Do you want to/are you able
to work on a patch?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
