|
Bugzilla – Full Text Bug Listing |
| Summary: | ncurses compatibility broken | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Jan Engelhardt <jengelh> |
| Component: | ConsoleApps | Assignee: | Petr Ostadal <postadal> |
| Status: | VERIFIED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | dickey |
| Version: | Beta 1 | ||
| Target Milestone: | --- | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Found By: | Beta-Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Testcase | ||
|
Description
Jan Engelhardt
2005-08-14 09:54:18 UTC
Installing the older ncurses-5.4-68 rpm from SUSE 9.3 again fixes all issues, including the gcc one. Gcc then prints no quotes whatsoever around said convmvaddr. Do _not_ mix two different versions. I'm not willingly to switch back to the old ncurses version due to the fact that the new one fixes several problems with UTF-8. Please recompile iptraf with the new ncurses version. I already did recompile it, that's why I posted this bug in the first place. Software involved: iptraf-2.7.0-192 ncurses-5.4-71 ncurses-devel-5.4-71 Hmm ... tell me, why I should switch back to the old ncruses version. It seems that iptraf is the only one which shows this problem. Even yast does not have any problem. Reasign it to the iptraf maintainer. Btw: does iptraf uses the wide character version of ncurses or the normal version? Reminder: I am using iptraf-2.7.0-192 (fresh from STABLE), and ncurses 5.4-71 (10.0 Beta 1), so no 9.3 issue. Normal version. But at best, ncurses should automatically handle it if the terminal is UTF-8 or not. It did that in the 9.3 rpm. This does not only affect iptraf, but external stuff like http://hte.sf.net/ to name one more example. What it does not affect is e.g. mc, but that uses slang on the other hand, rather than ncurses. The problem persists even if I make iptraf use -lncursesw. The unpatched iptraf 2.7.0 doesn't initialize its locale. Does SuSE's package fix that? (I don't see how it would work properly otherwise). I have never tried vanilla iptraf, only ever used the srpm from suse. I took a look at iptraf-2.7.0-188.src.rpm, and it doesn't call setlocale either in the original source or any of the patches. Unless there's some common library that calls setlocale, it won't work properly in a UTF-8 locale. Created attachment 48706 [details]
Testcase
If linked against ncurses-5.4-68, it prints a bar character at line 10. With
-71, it does not.
Linked against -lncurses; not -lncursesw. Though, BTW linking it against
ncursesw in -68 does not work either but I guess that's something different.
But if you add
#include <locale.h>
and
setlocale(LC_ALL, "");
it does work. That is a consequence of this change in ncurses:
20040228
+ check for nl_langinfo(CODESET), use it if available (report by
Stanislav Ievlev).
Before that change, ncurses would attempt to guess what locale one
should have initialized an application to. I don't think there's a
way to have both old/new behavior supported.
And how does it find out if the term is UTF8, if LC_ALL (implies LC_MESSAGES/LC_CTYPE) is erased? Looking at the stty settings? Anyway, some lot of ncurses apps need fixing. Close when done. The call
setlocale(LC_ALL, "");
tells the runtime libraries to look at the environment variables
to see what should be set. It's not an ncurses problem: for several
years, the only recommendation for dealing with locale issues has been
for the application to set its locale properly. There is _limited_
support for 8-bit character sets; UTF-8 does not fall into that class.
(If SuSE prefers to step backward 3-4 years and turn off the nl_langinfo
change, that's their choice ;-)
Yes, it works again if I put setlocale(LC_ALL,"") in HTE. thanks (report bugs). |