| Enrique Perez-Terron 2005-10-29, 2:49 am |
| On Fri, 28 Oct 2005 10:47:49 +0200, <marco.chiarandini@gmail.com> wrote:
> The UTF-8 is selected but the entry is shaded like the feature is not
> available.
> I found another strange behaviour: if I launch xterm from an xterm the
> charachters are fine.
> Using fvwm and launching xterm from the menu instead I have the
> unwanted behaviour describd. I still cannot understand which are the
> config files read in this case. It seems that none of the
> ~/.Xdefaults, ~/.Xresources or ~/.tcshrc affects xterm when launched by
> an xterm shell. I am lost!
You still forgot to tell us what you have in the LANG variable.
I have "en_US.UTF-8". Don't forget to export it (in sh, in (t)csh "setenv"
takes care of it).
Notice that there is a distinction between the LANG that the terminal emulator
sees and the one that the shell and its children sees. To set LANG for
the terminal emulator, either start the terminal emulator in a shell that
already has the correct LANG, or make sure the scripts run by your desktop
get the LANG you want. Unfortunately the exact sequence of events (program
invocations) from /sbin/init and /etc/inittab runs /etc/X11/prefdm, until
your desktop starts e.g. Nautilus (which starts gnome-terminal when you
use the context menu on the desktop root window), is a deep defense secret
that is prohibited from documentation under penalty of extradiction of your
entire family to Redmond.
There are some files in /etc/X11/xinit on my Fedora Core 4 system that
look vaguely like they could be part of the chain. Most likely they
exist only too fool the enemy.
On my system I have some processes:
PID PPID PGID SID CMD
2386 1 2386 2386 /bin/sh /etc/X11/prefdm -nodaemon
2398 2386 2386 2386 \_ /usr/bin/gdm-binary -nodaemon
2433 2398 2433 2386 \_ /usr/bin/gdm-binary -nodaemon
2444 2433 2444 2386 \_ /usr/X11R6/bin/X :0 -audit 0 -auth /var/gdm/:0.Xauth vt7
2580 2433 2580 2580 \_ /usr/bin/gnome-session
2643 2580 2643 2643 \_ /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /etc/X11/xinit/Xclients
2646 1 2580 2580 /usr/bin/dbus-launch --exit-with-session /etc/X11/xinit/Xclients
From this I would expect that dbus-launch will run Xclients, but there is
no such process, and reading the script, Xclients seems to exec gnome-session,
which is already a grand-parent of dbus-launch.
Looking at /etc/xinitrc, I find code to issue this dbus-launch command,
and ssh-agent is also talked about, but I cannot find the statement that
actually runs ssh-agent.
Following a hint in a comment, I look at /etc/X11/xdm/Xsession, which looks
more promising. If this is the missing link, it seems to source
/etc/profile.d/lang.sh. However, this all looks pretty Fedora-specific.
If you find out, you may find a place to add a "LANG=xxx; export LANG"
statement.
Whatever you try, you can check the result by looking up the process id
of your terminal emulator and do:
tr '\0' '\012' < /proc/1234/environ
on OSes that support /proc. Substitute the process id in question for "1234".
But if you are talking about the keyboard, and what the keyboard generates,
that's another question. Much of this is shrouded in mystery and "secret
documentation", and I only know part of the story. The keyboard setup starts
in the XF86Config or xorg.conf:
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "no"
EndSection
(Here "no" is for Norwegian.)
But this does not tell (to my knowledge) what encoding should be used for
the key characters. This points to a system of files in /usr/X11R6/lib/X11/xkb
where the values of the keys are ultimately specified using symbols like this:
key <AC10> { [ oslash, Ooblique, dead_acute, dead_doubleacute ] };
How these symbols get translated to encoded characters, I don't know.
I think it happens in X libraries in the client application, while the
X server only serves keycode numbers. It seems likely that again the
LANG setting in the application will govern this step.
I can elaborate more on Xkb, but I don't have it present enough at the
moment. If you ask, I will gladly dig it up again.
-Enrique
|