From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 Description of problem: In /etc/csh.login, when a user is using tcsh as a login shell, the dspmbyte shell variable is enabled. This variable enables unconditionally the Asian (CJK) language input code and makes it difficult to write european languages (tested with Greek). How reproducible: Always Steps to Reproduce: 1.Check /etc/csh.login whether it has set 'dspmbyte=euc' by default. I verified that in RH7.1 it is. 2. Enable Greek support in the X environment or possibly another similar language like russian. 3. Try to type in gnome-terminal (or xterm/...) in the local language. Actual Results: CJK is multibyte, meaning that you need to write two characters in order for the computer to have enough information to print the character. That is, when you press a key in the Greek keybaord, nothing appears until you press the next one. Example with latin-ized Greek to show the point. "_" shows cursor position. The following does not obviously work. For the real example and if you read greek, go to the URL. Pressed On_Screen L _ i Li n Expected Results: No multibyte code should be enabled. There should be a check in /etc/csh.login on whether the actual locale is one of CJK and only in that case set the dspmbyte=euc variable. Additional info:
Upon more rigorous inspection, /etc/csh.login belongs to: % rpm -q -f /etc/csh.login setup-2.4.7-1 Thus, it should be assigned to the "setup" maintainer and I should have checked the setup buglist.
This is a bug in the "setup" RPM.
FWIW, double-byte support in the Rawhide version of tcsh is turned off because it seems to be incompatible with ISO-8859 based input. If it's turned off, this envvar setting should be ignored.
Fixed in setup-2.5.3-1. In initscripts-6.13-1, lang.csh will set this for ja*, zh*, and ko* locales.