From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.16 i686) Description of problem: Entering Norwegian charcaters (fxe) can be difficult, especially f and e. x seems to work. "ff" gives only one f, or it might be a space and a f or some other odd combination. f follow by x works (first I get a space when I press f, but pressing x replaces the space with a f). LANG and LC_TYPE are set to no_NO, but I haven't found any settings that will give normal behavior. Some other charcters also seem to be affected: 4 and ( tcsh works normally in RH 6.2 and 7.0, and also if I compile the most recent release (6.11.00) from http://www.tcsh.org/page?MostRecentRelease Version-Release number of selected component (if applicable): 6.10-6 (and also release 4 from RH 7.1) How reproducible: Always Steps to Reproduce: 1. Use tcsh as shell 2. Make sure you have Norwegian language support (I have the variables LANG and LC_TYPE are set to no_NO) 3. Press f, x and e in various orders, also try to combine with other keys. Actual Results: f followed by o: <space>o just f: <space> f followed by f: <space>f, then the space is replaced by f The results may vary according to the order the letters are entered. Expected Results: The letters should have been entered normally. f should give f and so on. Additional info:
There seems to have some kind of error in submitting the special Norwegian characters. fxe are represented as fxe. I don't know how this will look when I submit this comment, but I do _not_ mean "eff" "eks" "ee", but "ae" "oe" and "ae".
The characters can be produces with compose - "/o", "aa", "ae".
It seems that Danish people are also hit with this bug. In Denmark we have three national characters fxe (Typical translation is ae, oe, aa). When I type on of these national characters I get a space Then I type the second national character I get both characters. This pattern now repeats.... "f" -> " " <-----!! "ff" -> "ff" "ffx" -> "ffx" "ffxe" -> "ffx " <-----!! "ffxee" -> "ffxee" I use RH7.2 with tcsh-6.10-6.i386.rpm The error can be cured by downgrading to tcsh 6.10-1 -> ftp://rpmfind.net/linux/redhat/updates/7.0/en/os/i386/tcsh-6.10-1.i386.rpm
The problem is the patch tcsh-6.10.00-dspmbyte.patch which does the following: - if (eq(pcp, dspmt[i].n)) { + if (strncasecmp (pcp, dspmt[i].n, strlen (dspmt[i].n))) { which is so wrong that it's embarrasing. The strings pcp (current locale) and dspmt[i].n (locale to look for) are 16-bit strings in this case, and: 1. strncasecmp does not handle 16-bit strings 2. strlen does not handle 16-bit strings 3. The result code is zero if equal, i.e. the test is reversed, and multibyte kanji input is enabled for everyone with a locale not beginning with 'j' or 'k'. Yuck! Please remove this sad excuse for a patch, and release a new tcsh RPM via up2date. The bug is serious, since it prevents entering local characters for many european countries, including Sweden, Norway and Denmark.
I forgot to mention that the workaround is to "unset dspmbyte".
I also support that a new tcsh-package is released. The bug is very annoying. I am also 99% sure that the bug is also found in Red Hat 7.1 as well as 7.2.
This also happens when trying to type any accented characters into a terminal window running tcsh under the "normal" en_US locale. It is extremely annoying to not to be able to rename a file that has an accent in its filename (I have to switch to bash or use a GUI thing!). Please do fix this thing! BTW, thanks to tobias.nu for the workaround, althought that is not a permanent solution.
This is embarrasing! Red Hat 7.3 was shipped with the same tcsh package which still is having the problems with european national letters like fxe. Please do something with this bug.
This bug is a duplicate of bug 41991
...which in turn is a duplicate of bug 41991
I got hit by this nastie too, and created new RPMs for our local use.
*** This bug has been marked as a duplicate of 41991 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.