homepage

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?

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.

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.

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>")'.

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 ~@

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.