Bug 33211 - Japanese cant be input under tsch on Kterm or rxvt
Summary: Japanese cant be input under tsch on Kterm or rxvt
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: tcsh   
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Eido Inoue
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-03-26 10:07 UTC by Bill Huang
Modified: 2005-10-31 22:00 UTC (History)
3 users (show)

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

Attachments (Terms of Use)

Description Bill Huang 2001-03-26 10:07:18 UTC

Japanese cant be input under tsch on kterm or rxvt.

Comment 1 Preston Brown 2001-03-26 22:31:56 UTC
more info please?  There seems to be massive regression on the japanese input 

Comment 2 Eido Inoue 2001-03-27 03:28:11 UTC
Looks like tcsh got compiled with it filtering the eighth bit out. Fixing.

Comment 3 Bill Huang 2001-03-27 04:04:25 UTC
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 06:45:33 UTC
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 11:19:18 UTC
This problem may be able to fixed by adding the following line to .tcshrc:

set dspmbyte=euc

Comment 6 Preston Brown 2001-03-27 16:30:31 UTC
fixed tcsh being built now.

Comment 7 Eido Inoue 2001-03-27 17:15:30 UTC
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 17:20:08 UTC
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 07:57:30 UTC
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.