Bug 89549 - Use autoset_dspmbyte instead of /etc/profile.d/lang.csh
Use autoset_dspmbyte instead of /etc/profile.d/lang.csh
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
: 72162 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2003-04-24 03:47 EDT by H. Peter Anvin
Modified: 2014-03-16 22:35 EDT (History)
4 users (show)

See Also:
Fixed In Version: 7.85-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-23 16:30:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fixes /etc/profile.d/lang.csh to set $dspmbyte properly. (336 bytes, patch)
2004-03-22 07:21 EST, Simos Xenitellis
no flags Details | Diff
Use glibc UTF-8 encoding name, don't stop at empty string (1.11 KB, patch)
2004-07-16 20:51 EDT, Miloslav Trmač
no flags Details | Diff
Don't set dspmbyte in /etc/profile.d/lang.csh (461 bytes, patch)
2004-09-23 05:55 EDT, Miloslav Trmač
no flags Details | Diff

  None (edit)
Description H. Peter Anvin 2003-04-24 03:47:28 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):

How reproducible:

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:
Comment 1 Alan 2003-09-28 20:20:00 EDT
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.  
Comment 2 Simos Xenitellis 2003-11-14 09:25:38 EST
[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.
Comment 3 Simos Xenitellis 2004-03-22 07:14:54 EST
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 zh*:
             set dspmbyte=euc
+       case *UTF-8:
+            set dspmbyte=utf8
+            breaksw
Comment 4 Simos Xenitellis 2004-03-22 07:21:29 EST
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".
Comment 5 Simos Xenitellis 2004-06-06 04:48:08 EDT
Please apply the mentioned patch.

It would be a shame to miss it on FC3 as well.
Comment 6 Miloslav Trmač 2004-07-16 20:51:58 EDT
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.
Comment 7 H. Peter Anvin 2004-07-27 13:05:29 EDT
I believe that would be by far the best solution.
Comment 8 Miloslav Trmač 2004-08-17 10:42:49 EDT
*** Bug 72162 has been marked as a duplicate of this bug. ***
Comment 9 Miloslav Trmač 2004-08-18 06:13:03 EDT
tcsh-6.13-1 sets dspmbyte automatically.
Comment 10 Miloslav Trmač 2004-09-14 15:01:29 EDT
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).
Comment 11 Miloslav Trmač 2004-09-23 05:55:16 EDT
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 :).
Comment 12 Bill Nottingham 2004-09-23 11:47:50 EDT
Should new tcsh be required?
Comment 13 Miloslav Trmač 2004-09-23 16:15:58 EDT
The distribution in general does not require tcsh AFAICS, maybe
        Conflicts: tcsh < 6.13-5
if that does what I think it does.
Comment 14 Bill Nottingham 2004-09-23 16:30:59 EDT
OK, will be fixed in initscripts-7.85-1 or later.

Note You need to log in before you can comment on or make changes to this bug.