From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 Description of problem: Some problems with Midnight Commander and UTF8 can be avoided by modifying the "mc-wrapper.csh" and "mc-wrapper.sh" in the directory "/usr/share/mc/bin". This is an easy workaround and by no means a solution, but until the problem with UTF8 is solved upstream it will do fine (at least for me). Needed change in "mc-wrapper.csh" : 7c7 < /usr/bin/mc -P "$MC_PWD_FILE" $* --- > /usr/bin/mc -a -P "$MC_PWD_FILE" $* Needed change in "mc-wrapper.sh" : 2c2 < /usr/bin/mc -P "$MC_PWD_FILE" "$@" --- > /usr/bin/mc -a -P "$MC_PWD_FILE" "$@" Applying this change makes Midnight Commander a lot more stable; it will not crash for me anymore drawing high-ascii characters. Version-Release number of selected component (if applicable): mc-4.6.0-6 How reproducible: Always Steps to Reproduce: 1. Start "mc" with (for example) the following settings : LANG="nl_NL.UTF-8" SUPPORTED="nl_NL.UTF-8:nl_NL:nl:en_US.UTF-8:en_US:en" SYSFONT="latarcyrheb-sun16" 2. Turn on the 'info panel' on the left. Actual Results: Midnight Commander hangs and uses 100% CPU time. Expected Results: It should not hang. Additional info:
Is the crash you are speaking of in mc, or in one of the libraries? Did you file that crash? Bug number? It seems you are speaking of different bugs here (100% CPU and a crash). Also, although it is good to know one can use such a wrapper, in my opinion we should not implement a workaround that only obscures a (potentially exploitable) crash. I would say WONTFIX, but please bugzilla the crash and the 100% CPU issues by themselfs.
Described problem still occurs in Fedora Core release 2 (Tettnang) with the following packages : - "mc-4.6.0-15" - "slang-1.4.9-3.1" I suspect the origin of this bug lies with the usage of the system-wide S-lang library in Fedora. Basically, mc 'hangs' when started with the following settings (see "/etc/sysconfig/i18n") : LANG="nl_NL.UTF-8" SUPPORTED="nl_NL.UTF-8:nl_NL:nl:en_US.UTF-8:en_US:en" SYSFONT="latarcyrheb-sun16" When it hangs, I mean that mc won't even display it's blue panels when the info panel on the right or left side is turned on. And when this happens mc is using 100% CPU time and must be killed with e.g. the command "killall mc". I downloaded the sources for mc ("mc-4.6.0.tar.gz") from the official site (http://www.ibiblio.org/mc/) and compiled mc with different options. Interestingly, when I build mc with the following command : "./configure --prefix=/opt/mc-4.6.0" the build process says : 'configure: WARNING: Rejecting S-Lang with UTF-8 support, it doesn't work well' When I start the resulting binary (build using the included S-Lang library, "mcslang") mc does *not* hang on my system. And when I rebuild mc with the option "--with-screen=slang" the resulting binary, just as the one in the Fedora distribution, *hangs* on my system. So it seems the problem lies upstream somewhere. The configure script in the upstream package avoids the UTF-8 stuff with the system-wide S-Lang library (by using the option "--with-screen=mcslang") because it is not 100% reliable and Fedora builds the mc binary with the option "--with-screen=slang", causing mc to bork out with some UTF-8 systems. In the TODO list on the official page (http://www.ibiblio.org/mc/TODO) the authors of mc mention proper support for multi-byte charsets (UTF-8) systems in a future version (the 4.7 branch) of mc. I think I'll close this bug as UPSTREAM because the authors of mc are already aware of the UTF-8 issues with mc. And Leonard, just as you said, a wrapper might not be a good idea for everybody because it only obscures the problem and some people (Arabic and Asian languages?) might *need* the current UTF-8 support. Also, the Fedora project has made the transition to UTF-8 for its included components, so changes to the mc.spec file to use "--with-screen=mcslang" instead of "--with-screen=slang" might not be a good idea.