0

When trying to run stuff like https://github.com/asciimoo/drawille/blob/master/examples/rotating_cube.py

Using my normal user I always get weird characters like

M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM-!~OM-bM- ~IM-bM- ~IM-bM- ~IM-bM- ~IM-bM- ~IM-bM- ~IM-bM- ~IM-bM- ~IM-bM- ~IM-bM- ~IM-bM- ~IM-bM- ~IM-bM- ~IM-bM- ~IM-bM- ~IM-bM- ~IM-bM- ~IM-bM- ~IM-bM- ~IM-bM-!~GM-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@ M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M-bM- ~@M

when running using root looks normal, my terminal prints unicode characters correctly when doing stuff like

python -c 'print unichr(0x28ff)' or echo -e '\u285a'

and $TERM is set to xterm in both user environments, any hint would be welcome.

Thanks

snebel29
  • 179
  • 2
  • 6

2 Answers2

0

Your "normal user" doesn't have the locale set so that ncurses sees that it supports UTF-8 encoding. To see the difference, run the locale command as your normal user, and compare it with the output when running as root.

The M, by the way, means "meta", which denotes a character with the eighth (most-significant) bit set. Back in the day when 7-bit ASCII was common, and 8-bit characters relatively new, some people decided to treat that specially. If your locale is not set (i.e., POSIX), that's essentially 7-bit ASCII.

Some of that (including the use of M- as a prefix) is mentioned in the manual page for unctrl.

Regarding the followup (which relies upon information not in the question), that's an old problem with Python which I'd thought was fixed. As I pointed out in python+ncurses: I can't display accents, Python doesn't really distinguish between ncurses and ncursesw based on their interfaces, but only their name, and that some other components may load the wrong name before you get to the curses module:

It's more complicated than that: python's loading "ncurses" dynamically.

It doesn't matter much (to python) which one it loads, but it's specifying the library name explicitly. At the same time, some other packages (such as readline) are separately loading the ncurses library - and they also specify a library name. Rather than abstracting that stuff out to another (more easily changed) level, it's embedded in the code.

If the initialization script is changed to load "ncursesw" then python can use ncursesw without further change. There are a few patches to the configuration that I've seen mentioned in the bug reports to enable python to do this. Those are patches to python of course...

(this was a topic of discussion on this newsgroup about a year ago).

Thomas Dickey
  • 51,086
  • 7
  • 70
  • 105
  • Hi Thomas, `diff <(locale) <(sudo locale)` shows no difference hence both are the same, will try to see if locale stay the same within python context and will take a look to unctrl to understand better what's going on and try to find where the configuration issue is... – snebel29 Mar 15 '17 at 09:32
  • Still unlucky, `python -c "import locale; print(locale.getdefaultlocale())"` with both users print `('en_IE', 'UTF-8')`, the same result when adding that to a script using curses – snebel29 Mar 15 '17 at 11:39
0

Googling finally fixed the issue by reinstalling the python 3.4.3 interpreter, looks like the python curses dynamic library

$ ll /home/snebel29/.pyenv/versions/*/lib/python*/lib-dynload/*cur*
-rwxr-xr-x 1 snebel29 snebel29  42620 Jan 28  2016 /home/snebel29/.pyenv/versions/2.6.6/lib/python2.6/lib-dynload/_curses_panel.so*
-rwxr-xr-x 1 snebel29 snebel29 254035 Jan 28  2016 /home/snebel29/.pyenv/versions/2.6.6/lib/python2.6/lib-dynload/_curses.so*
-rwxr-xr-x 1 snebel29 snebel29  42520 May 16  2015 /home/snebel29/.pyenv/versions/2.7.6/lib/python2.7/lib-dynload/_curses_panel.so*
-rwxr-xr-x 1 snebel29 snebel29 254661 May 16  2015 /home/snebel29/.pyenv/versions/2.7.6/lib/python2.7/lib-dynload/_curses.so*
-rwxr-xr-x 1 snebel29 snebel29 320512 Mar 15 11:50 /home/snebel29/.pyenv/versions/3.4.3/lib/python3.4/lib-dynload/_curses.cpython-34m.so*
-rwxr-xr-x 1 snebel29 snebel29  46244 Mar 15 11:50 /home/snebel29/.pyenv/versions/3.4.3/lib/python3.4/lib-dynload/_curses_panel.cpython-34m.so*

should point to libncursesw.so.5

$ ldd /home/snebel29/.pyenv/versions/3.4.3/lib/python3.4/lib-dynload/_curses.cpython-34m.so
    linux-vdso.so.1 =>  (0x00007fffecad1000)
    libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x00007f868e9d0000)
    libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f868e7a7000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f868e589000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f868e1c4000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f868dfc0000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f868ee1b000)

and somehow was pointing to libncurses.so.5, see here for my 2.7.6 interpreter where this is still faling

$ ldd /home/snebel29/.pyenv/versions/2.7.6/lib/python2.7/lib-dynload/_curses.so
    linux-vdso.so.1 =>  (0x00007ffcb3f60000)
    libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5 (0x00007feed55be000)
    libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007feed5395000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007feed5177000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007feed4db2000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007feed4bae000)
    /lib64/ld-linux-x86-64.so.2 (0x00007feed59f5000)

However I still don't get why on library works and not the other and specially why running with root account make it works...

snebel29
  • 179
  • 2
  • 6