Bug 33211 - Japanese cant be input under tsch on Kterm or rxvt
Japanese cant be input under tsch on Kterm or rxvt
Product: Red Hat Linux
Classification: Retired
Component: tcsh (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Eido Inoue
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-03-26 05:07 EST by Bill Huang
Modified: 2005-10-31 17:00 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-03-27 06:19:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bill Huang 2001-03-26 05:07:18 EST

Japanese cant be input under tsch on kterm or rxvt.
Comment 1 Preston Brown 2001-03-26 17:31:56 EST
more info please?  There seems to be massive regression on the japanese input 
Comment 2 Eido Inoue 2001-03-26 22:28:11 EST
Looks like tcsh got compiled with it filtering the eighth bit out. Fixing.
Comment 3 Bill Huang 2001-03-26 23:04:25 EST
To reproduce the bug:
1.start up kterm or rxvt
2.change to tcsh
3.press "Shift" + "space" to enable kinput2 for inputting japanese
4.input Japanese,japanese can be converted correctly, though it cant be
displayed on the terminal.
Comment 4 Eido Inoue 2001-03-27 01:45:33 EST
This is not a bug with tcsh... the rebuilt tcsh source package works asis in
Japanese on Vine and other Japanese Linuxes... something has changed with the
environment surrounding tcsh. Investigating.
Comment 5 Akira TAGOH 2001-03-27 06:19:18 EST
This problem may be able to fixed by adding the following line to .tcshrc:

set dspmbyte=euc
Comment 6 Preston Brown 2001-03-27 11:30:31 EST
fixed tcsh being built now.
Comment 7 Eido Inoue 2001-03-27 12:15:30 EST
How did you do this with tcsh?

Shouldn't the setup package be changed (csh.login)? (this is where I added the
delete-key fix for tcsh) I was thinking the shell script should check the env to
see if it's tcsh and the LANG/LC_CTYPE is set to a Japanese locale... I haven't
tested the above to see if it's compatible with European/Latin-1 locales.
Comment 8 Eido Inoue 2001-03-27 12:20:08 EST
Actually, now that I think about it, EUC is EUC whether its Korean, Japanese, or
Simplified Chinese, so if the locale is checked, it's safe to look for the
substring (case insensitive) "euc" so it will hit "ja_JP.eucJP" as Korean and
Chinese locales as well.
Comment 9 Akira TAGOH 2001-03-28 02:57:30 EST
This problem occurred from glibc2.2.
Actually tcsh set dspmbyte automatically.
however tcsh can't see the locale correctly.
we will need the following patch:

diff -ruN tcsh-6.10.00.orig/sh.set.c tcsh-6.10.00/sh.set.c
--- tcsh-6.10.00.orig/sh.set.c	Wed Mar 28 16:44:53 2001
+++ tcsh-6.10.00/sh.set.c	Wed Mar 28 16:53:23 2001
@@ -41,6 +41,8 @@
 #include "ed.h"
 #include "tw.h"
+#include <string.h>
 extern Char HistLit;
 extern bool GotTermCaps;
@@ -1211,7 +1213,7 @@
     for (i = 0; dspmt[i].n; i++) {
-	if (eq(pcp, dspmt[i].n)) {
+	if (strncasecmp (pcp, dspmt[i].n, strlen (dspmt[i].n))) {
 	    set(CHECK_MBYTEVAR, Strsave(dspmt[i].v), VAR_READWRITE);

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