[Fedora-i18n-list] utf-8 national character input in Linux Konsole/KDE/X?

[Mikko Harjula]

Leon Ho writes:
> Hi Mikko,
> 
> How does this compare to gnome-terminal?
> 
> And have you tried to change the Settings -> Encodings to 'UTF-8' in konsole 
> and see if it works?

Hi Leon,

Thanks for your input but I found the problem.  The solution came from
Enrique Perez-Terron in comp.os.linux.setup newsgroup. He helped me to
compare several config files which helped me to avoid wasting my
efforts to something that is correct. Also I got several good hints
from him:

- The 'ls | od' is not a good test to check the output of ls-command
  as ls behaves differently when the output is terminal (now I used to
  know this!). A better way is to use:

      script
      ls
      exit
      od -c typescript 

- Another great idea was to check the environment of a running program
  from /proc/PID/environ.

- Third we compared the environment and output of the xev-command and
  indeed for him the XLookupString returned 2 bytes and a valid utf-8
  code when for me it returned one garbage byte!

- The finally decisive idea was to use strace -e trace=file
  locale. This revealed:

    open("/usr/lib/locale/posix/LC_COLLATE", O_RDONLY) = -1 ENOENT (No such file or directory) 

  and the whole directory /usr/lib/locale/posix actually is missing.
  So the problem was all the time the LC_COLLATE=posix!

  I have had this as long as there has been iso-8859-1 locale. As a
  programmer I like to see Makefile and README first in the directory
  listing and all over the net everyone tells to use locale
  'posix'. Well this does not exist in FC4. There is locale 'C' which
  seems to produce similar result in LC_COLLATE.

So, problem solved!!! Now national character input works OK and ls
lists filenames OK!  Hope this info helps someone else.

It seems to me the LC_COLLATE setting should not affect the results of
other locale variables, but maybe the locale processing dies in the
middle when it encounters an unknown setting.  So I can see where this
could come from.  There may be some need to improve the robustness of
locale processing in glibc.

-- 
Mikko Harjula                   puh. 010-525 1555
mikko.harjula at mediware.fi       gsm  040-778 6669