Thomas Dickey wrote: > On Thu, Sep 08, 2005 at 11:40:18PM +0200, Vedran FuraÄ? wrote: > >>Yes, the same thing is in the linux console. What do you mean under >>"UTF-8 mode", locale settings or something else? I have tried different >>locale settings but that didn't help. > > > When Linux console is initialized to handle UTF-8 output, it behaves with > iptraf just as your picture of konsole. The console code ignores the > vt100-style line-drawing described in its terminfo. So applications running > in the console when it's in that mode must use the UTF-8 encoding for the > look-alike Unicode values that are in the font loaded for the console. > > Changing your locale settings won't change the mode of the console - that's > done by sending an escape sequence to it. Also, resetting the terminal > makes it go back to vt100-mode. Altogether, not a very good design, but > it's out there in millions of computers. > > Since iptraf doesn't pay any attention to the locale settings (and doesn't > initialize its locale), ncurses can only assume that it's either a POSIX > locale or the legacy (for configurations _without_ locale support), 8-bit > encoding.
Thanks for explanation. As a test I changed the mode (echo -ne '\033%@') ant it worked. But I must use UTF-8 mode. >>>The application must take this into account. For ncurses, that's done by >>>setting up the locale support within the calling application. >> >>So, there is no quick solution for this, no workarounds? I'll just have >>to wait? Am I the only one experiencing this problem? > > The quick workaround for iptraf is to add > #include <locale.h> > and > setlocale(LC_ALL, ""); Thanks! That solves the problem. Should I file the bugreport on iptraf? I think you can close this bug. -- Vedran Furač
