Red Hat Bugzilla – Bug 89549
Use autoset_dspmbyte instead of /etc/profile.d/lang.csh
Last modified: 2014-03-16 22:35:54 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 Description of problem: The RedHat installation of tcsh defaults to "dspmbyte euc". This means that it doesn't work in any locale which *isn't* using Japanese EUC encoding. For 8-bit locales, dspmbyte should be unset; for UTF-8 locales it should be set to "utf8". What's worse, "dspmbyte utf8" isn't supported by the RedHat tcsh -- presumably it is not compiled in. Version-Release number of selected component (if applicable): tcsh-6.12-4 How reproducible: Always Steps to Reproduce: 1. Use an 8-bit system locale, e.g. en_US 2. Try to enter 8-bit characters at the tcsh prompt 3. Use an UTF-8 system locale, e.g. en_US.utf8 4. Try to enter UTF-8 text at the tcsh prompt Actual Results: Failure, unless I manually "unset dspmbyte" (or put that into /etc/csh.cshrc or a similar file.) The UTF-8 locale doesn't work at all; "set dspmbyte utf8" which is correct according to the manpage doesn't work. Additional info:
Confirmed this on several systems. Basic operations such as "man" completly fail in default RH9 installs under tcsh unless /etc/sysconfig/i18n is changed from the default en_US.utf8 to plain en_US. -alan
[Joining from http://bugzilla.fedora.us/show_bug.cgi?id=951] tcsh allows writing of non-latin scripts if the $dspmbyte variable has a proper value. Typical values for this variable are "euc" and "utf8". The first is for Asian scripts. When LANG=el_GR.UTF8 (at least), this variable is set up "euc" instead of the proper "utf8". I did not see a way where the proper value of $dspmbyte is set depending on the variable $LANG. Should the setup scripts of Fedora do the check (if $LANG=cn, $dspmbyte=euc") or we should annoy the tcsh maintainer to include such a test in the executable? The following % set dspmbyte=utf8 works wonderfully for the Greek locale. A user can write Greek properly, just as with bash.
Applying the following 3-line patch appears to fix the problem. The script /etc/profile.d/lang.csh does not set the dspmbyte variable properly. The script DOES set $dspmbyte properly for non-UTF8 CJK languages. For the rest of the cases it does not set the variable at all and it picks "euc" which is incorrect. As most of the locales nowdays are xx_LL.UTF-8, "utf8" is the appropriate value for $dspmbyte. The patch acts as a simple "default:" in the "switch" statement of the script to set $dspmbyte to "utf8" for all the rest of the *.UTF-8 locales. Works for el_GR.UTF-8. Please apply the patch and close bug. ===================================> *** /etc/profile.d/lang.csh.ORIGINAL 2004-03-22 17:05:24.000000000 +0800 --- /etc/profile.d/lang.csh 2004-03-22 19:53:48.000000000 +0800 *************** if ($?LANG) then *** 110,114 **** --- 110,117 ---- case zh*: set dspmbyte=euc breaksw + case *UTF-8: + set dspmbyte=utf8 + breaksw endsw endif
Created attachment 98746 [details] Fixes /etc/profile.d/lang.csh to set $dspmbyte properly. $dspmbyte is not set properly and for a broad number of languages it is set to the unsuitable value of "euc" (a CJK type of writing method?). The correct value is "utf8".
Please apply the mentioned patch. It would be a shame to miss it on FC3 as well.
Created attachment 101990 [details] Use glibc UTF-8 encoding name, don't stop at empty string The other possibility is to upgrade to tcsh-6.13.00, which sets dspmbyte automatically from LC_CTYPE or LANG, and apply this bugfix. The code in /etc/profile.d/lang.csh for setting dspmbyte could then maybe be completely removed.
I believe that would be by far the best solution.
*** Bug 72162 has been marked as a duplicate of this bug. ***
tcsh-6.13-1 sets dspmbyte automatically.
tcsh-6.13-5 should set dspmbyte for all cases correctly handled by lang.csh, code in lang.csh can be removed after 6.13-5 hits rawhide (after FC3t2).
Created attachment 104172 [details] Don't set dspmbyte in /etc/profile.d/lang.csh Current rawhide tcsh sets dspmbyte automatically, so the code in lang.csh can be removed. This can actually be an improvement - the lang.csh code would set dspmbyte=euc even for zh_CN.gbk and zh_CN.gb18030 (not to talk about zh_CN.ISO-8859-2 :).
Should new tcsh be required?
The distribution in general does not require tcsh AFAICS, maybe Conflicts: tcsh < 6.13-5 if that does what I think it does.
OK, will be fixed in initscripts-7.85-1 or later.