Salut Jean-Michel,
BESSOT Jean-Michel wrote on Fri, Mar 07, 2025 at 06:36:08PM +0100:
Le 3/7/25 17:03, Jan Stary a ecrit:
On Mar 07 16:54:36, jean-michel.bes...@lacomte.net wrote:
the accented characters show when I start the terminal manually
after the start of spectrwm.
This shows us that
(1) the xterm configuration files, see the FILES section in the xterm(1)
manual,
(2) the way you start xterm(1) manually,
(3) and perhaps some other aspects
correspond to the OpenBSD defaults on your machine, at least as far as
xterm encoding configuration (which is extremely complicated and
overengineered way beyond the point of absurdity) goes.
[ order of quotations changed ]
env from the automatically started xterm:
The fact that both environments agree means that the environment is
unlikely to cause the problem - theoretically, it might be possible that
spectrwm passes some environment variable to xterm that xterm does not
pass on to the shell it starts, but that does not sound like a probable
explanation to me.
Theoretically, the problem could also be related to tmux(1), so you
could try to take tmux(1) out of the picture. But i doubt that will
help. UTF-8 bugs in tmux(1) are not unheard of, but extremely rare
nowadays.
But the one launched automatically with spectrwm does not
show characters.
Consequently, the most likely culprit is spectrwm, for example
(a) an outright bug in the spectrwm code
(b) a misconfiguration of spectrwm that exists by default
(c) or a unique misconfiguration of spectrwm on your machine.
For example, spectrwm might be passing bad command line options to
xterm(1),
for example something involving -en, or +lc, or -loc, or +u8, or -xrm.
There are very large numbers of very diverse possibilities what spectrwm
could be doing wrong here. Other people can at best speculate what's going
on on your machine, you'll probably have to dig into it yourself.
One obvious way to investigate which command line options xterm(1)
is started with would be
$ ps -Awwo command | grep xterm
but unfortunately, xterm(1) appears to hide its command line options from
ps(1), and all i see is this:
/bin/sh -c xterm -ls -geometry 80x80
/usr/X11R6/bin/xterm
The first one of the pair of lines above is how my fvwm(1) start xterm(1),
the second one is the running xterm(1) itself - failing to report the
-ls and -geometry options it got. If spectrwm, like fvwm(1), also uses
a subshell to start xterm(1), the above command might help you; if
it uses something like fork(2)+execve(2) directly, it probably won't.
If spectrwm creates a log file somewhere that captures the output
of processes it spawns, you could try to reconfigure spectrwm to
pass the -report-xres option when starting xterm, such that you can
inspect the output and optionally compare to the output generated by
running "xterm -report-xres" manually. That might at least provide
some clues in which corner to continue searching.
If you want to debug spectrwm the hard way, try running spectrwm
under ktrace(1). That way, you will almost certainly be able to see
what spectrwm is doing to start xterm(1) - but wading through the
large amount of output from ktrace(1) will likely require some skill.
Terms launch tmux. I am not sure of what you call a Login Shell.
Look at
$ man -O tag=l ksh
to understand what "Login Shell" means in the context of ksh(1).
It might be theoretically possible that question is somehow related
to your problem, but it does not seem particularly likely to me.
I guess it's more likely that spectrwm is broken or misconfigured
than that xterm(1) or ksh(1) are causing the problem.
Good luck,
Ingo
