[Cc: MAINTAINER = gonzalo@ bket@ - this is about your port spectrwm]
Salut Jean-Michel,
BESSOT Jean-Michel wrote on Mon, Mar 10, 2025 at 03:45:20PM +0100:
> Le 3/9/25 23:27, Ingo Schwarze a ecrit:
>> In the xterm+tmux+ksh started by "autorun = ws[1]:xterm -e tmux",
>> accented characters are not displayed; when i change that to
>> "autorun = ws[1]:xterm", they are, and when i then start tmux(1)
>> manually in the resulting terminal, they still are.
>> When i run "xterm -e tmux" manually, they are displayed, too.
>> (If that is what you see - otherwise, describe it correctly!)
> It is what I see. I did see also I have the problem when I run
> xterm -e tmux from dmenu.
>> It might be even better to be slightly more precise:
>> In the case where accented characters do not work, what exactly happens when
>> 1) typing an accented character in that terminal
> it writes _
>> 2) cat(1)ing a file containing an accented character to that terminal
>> Nothing displayed at all? Some escape sequences displayed?
>> Something totally wrong displayed?
> The accented characters are changed for _
Now i have a strong suspicion what is likely going on.
Consider this paragraph in the tmux(1) manual:
ENVIRONMENT
LC_CTYPE The character encoding locale(1). It is used for two separate
purposes. For output to the terminal, UTF-8 is used if the -u
option is given or if LC_CTYPE contains "UTF-8" or "UTF8".
Otherwise, only ASCII characters are written and non-ASCII
characters are replaced with underscores (`_').
# ^- This is what caught my attention - i doubt that
# any other of the programs involved (xterm, ksh)
# would do such a replacement.
For input, tmux always runs with a UTF-8 locale. If en_US.UTF-8
is provided by the operating system, it is used and LC_CTYPE is
ignored for input. Otherwise, LC_CTYPE tells tmux what the
UTF-8 locale is called on the current system. If the locale
specified by LC_CTYPE is not available or is not a UTF-8
locale, tmux exits with an error message.
Consider what it means if spectrwm does *not* set LC_CTYPE
in the program it spawn via autorun:
* autorun = ws[1]:xterm -e tmux
- spectrwm spawns xterm without LC_CTYPE
- xterm spawns tmux without LC_CTYPE
At this point accented chars get replaced with underscores in output
- tmux spawns ksh without LC_CTYPE
- ksh reads your shell initialization files setting LC_CTYPE
But that comes too late, tmux is already misconfigured.
* autorun = ws[1]:xterm , then later run tmux interactively
- spectrwm spawns xterm without LC_CTYPE
- xterm spawns ksh without LC_CTYPE
- ksh reads your shell initialization files setting LC_CTYPE
So now accented characters work.
- You run tmux manually.
Now LC_CTYPE is set in the environment of tmux and tmux does
not replace accented characters with underscores.
Actually, i'm now able to reproduce your problem *without spectrwm*
as follows:
1. Start an xterm(1) in fvwm(1).
2. Inside the shell in that xterm, run "unset LC_CTYPE"
3. Inside the same shell, run "xterm -e tmux"
4. Inside the resulting window, run "echo $LC_CTYPE"
-> That results in en_US.UTF-8 (due to my shell initialization files).
5. Type the French word for "summer" -> _t_
6. Run "echo _t_ | wc -c"
-> Prints the number 6 because -c counts bytes and e accent aigu
is two bytes, so we have 2+1(t)+2+1(\n) = 6 bytes.
That weans that the shell actually works correctly, including correct
processing of accented characters, even in the broken state.
Only tmux *output* replaces the characters, input still works.
Please try whether the following workaround works for you.
Instead of
autorun = ws[1]:xterm -e tmux
please try
autorun = ws[1]:xterm -e tmux -u
Does that hide the problem on your machine?
Please make sure that the following alternative workaound also helps:
autorun = ws[1]:xterm -e /bin/ksh -lc tmux
Even even one of these workarounds does not work for you, my understanding
is still wrong.
Now let's progress to the next stage, deciding whether there is a bug,
and in which program.
1. I do not see any indication of a bug in ksh(1).
2. I think tmux(1) is doing the right thing.
It should not print invalid characters to the terminal
bacause that might be dangerous, potentially scrweing up the
terminal or even triggering functionality unintended by the user.
(For that reason, i did not Cc: nicm@.
If somebody thinks tmux(1) could do something better,
we can still talk to him, but i see no need at this point.)
3. I do not see any indication of a bug in sterm(1).
4. The behaviour of spectrwm, on the other hand, feels dubious to me,
That why i Cc:ed MAINTAINER.
Shouldn't spectrwm use the user's shell configuration files
when spawning autorun? I'm not absolutely certain it should,
i'm not maintaining a window manager, but the question seems
legitimate to me.
> Never used ktrace, I need to read the man.
If both of the above workarounds works for you, no need to learn ktrace(1)
right now - then again, learning it is no doubt useful in the long run. ;-)
Yours,
Ingo
