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):
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.
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.
[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?
% 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
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
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 *UTF-8:
+ set dspmbyte=utf8
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
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.