more info please?  There seems to be massive regression on the japanese input 
front.

Looks like tcsh got compiled with it filtering the eighth bit out. Fixing.

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.

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.

This problem may be able to fixed by adding the following line to .tcshrc:

set dspmbyte=euc

fixed tcsh being built now.

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.

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.

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 @@
 	return;
 
     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);
 	    update_dspmbyte_vars();
 	    break;