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: python/ncurses bug in 2.4.3 with extended ascii
Type: Stage:
Components: Extension Modules Versions: Python 2.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: akuchling, loewis, unixops1234
Priority: normal Keywords:

Created on 2006-06-05 22:34 by unixops1234, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (6)
msg28713 - (view) Author: UnixOps (unixops1234) Date: 2006-06-05 22:34
There is a problem displaying extended ascii characters
in ncurses through python, which does not exist in
versions prior to 2.4.2. I am running RedHat Enterprise
Linux WS 3 with updated patches, using the system
version of ncurses (ncurses-5.3-9.4 and devel). When
building a vanilla python 2.4.3 from source, printing
extended ascii characters in ncurses fails:

$ cat test.py
import curses

screen = curses.initscr()

screen.addstr("\x80")

screen.getch()
curses.endwin()

$ python test.py
Traceback (most recent call last):hon test.py
File "test.py", line 5, in ?
screen.addstr("\x80")
_curses.error: addstr() returned ERR

This should produce a blank ncurses screen, rather than
the addstr() error. I've been able to confirm that it
works with python 2.4.2 and earlier. 

To ensure that ncurses was able to display the
character, I wrote this test C program: 

$ cat test.c
#include <ncurses.h>

int main()
{
initscr();
int rtn = addstr("\x80");
getch(); 
endwin();
printf("The return value was %d.\n",rtn);
return 0;
}

$ gcc test.c -o test -lncurses
$ ./test

This works just fine, so I think the problem lies
somewhere in the python interface to ncurses. Python
can print this character without errors when not using
ncurses. Perhaps ncurses is expecting different
initialization than python is providing.  

I've also tested this on a RedHat WS 4 machine, where
it works just fine. This system is running
ncurses-5.4-13 and ncurses-devel-5.4-13. It seems the
newer release of python has changed something that the
older versions of ncurses are unable to handle.  

Can this be fixed in _cursesmodule.c?
msg28714 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-06-08 17:58
Logged In: YES 
user_id=21627

I doubt it can be fixed in _cursesmodule. Notice that Python
links with ncursesw now, not with ncurses anymore. There is
a bug in 2.4.3 which links, apparently incorrectly, with
panel instead of panelw. Try changing that and see whether
it helps.
msg28715 - (view) Author: UnixOps (unixops1234) Date: 2006-06-08 20:02
Logged In: YES 
user_id=1534776

I tried recompiling Python with the patch from bug #1464056
that fixes the panelw linking in _curses_panel.so. It now
properly links with libpanelw instead of libpanel, but the
original problem persists. I still get "_curses.error:
addstr() returned ERR" when running the test code.
msg28716 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2006-07-26 18:45
Logged In: YES 
user_id=11375

The ncurses 5.5 changelog, currently at
http://www.gnu.org/software/ncurses/ncurses.html, contains
this entry:

  * use setlocale() to query the program's current locale
rather than using getenv(). This supports applications which
rely upon legacy treatment of 8-bit characters when the
locale is not initialized.

So maybe this is a problem in ncurses 5.4 that can be
avoided if your Python script calls 'locale.setlocale("<some
locale that uses Latin-1>")'.
msg28717 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-07-26 20:39
Logged In: YES 
user_id=21627

unixops1234, can you please explain what "works just fine"
for the C code means? \x80 is not a meaningful character for
the terminal. On my system (Debian with ncurses 5.5, locale
de_DE.UTF-8, konsole), the program prints something, namely
the characters ~@
msg28718 - (view) Author: UnixOps (unixops1234) Date: 2006-07-31 22:33
Logged In: YES 
user_id=1534776

akuchling, thanks. Your suggestion worked. I added

import locale
locale.setlocale(locale.LC_ALL, 'en_US')

to the beginning of my test.py script and it correctly
displayed the funky character.

loewis, what I meant is that the C code correctly printed a
strange character instead of crashing with a curses error
message. 

The panelw patch is not needed after all. The test.py script
also works just fine if I build python against ncurses 5.5
instead of 5.4.

Thank you both for your help with this.
History
Date User Action Args
2022-04-11 14:56:17adminsetgithub: 43463
2006-06-05 22:34:08unixops1234create