On 2020/06/01 15:56, Stéphane Aulery wrote: > Le 01/06/2020 15:46, Matthieu Herrb a écrit : > > On Mon, Jun 01, 2020 at 03:28:52PM +0200, Stéphane Aulery wrote: > > > Le 01/06/2020 14:55, Matthieu Herrb a écrit : > > > > > > > > > > > > > > (I have just tried with a test user with nothing configured besides > > > > > LC_CTYPE=en_US.UTF-8, without which xterm/vim doesn't show proper > > > > > characters) > > > > > > > > I'm using a real US keyboard with AltGr or the Menu Key (depending on > > > > the actual keyboard) set as Compose and typing full compose sequences > > > > to get diacritics. ie <Compose> <comma> <c> and so on. > > > > > > I use a Bépo keyboard but this but > > > > > > Your experience interests me. I use a Bépo keyboard but I plan to > > > switch to > > > a QWERTY + compose keyboard like you do. I hope this will give better > > > compatibility between systems and less software config remapping. > > > > > > I do not see how to configure this in console. > > > > I'm only using this under X. the OpenBSD console is plain ASCII and > > has no support for for UTF8 characters, so no need to enter them. > > This explains why I cannot enter accented characters through SSH. I can't > edit a plain UTF-8 file remotely then... when the server has no X server > running. Doh!
It doesn't matter if the server is running X or not, it is down to the terminal used on the machine with the SSH client, and the setting for LC_CTYPE. By default ssh passes TERM to the server but not LC_CTYPE. You might find it helpful to set "SendEnv LC_CTYPE" in .ssh/config on the client and "AcceptEnv LC_CTYPE" in /etc/ssh/sshd_config on the server (some other OS do this by default).
