13

Scenario:

I have a server, on which a tmux session is running. Let's call that session tmux_session in the rest of this post.

Attaching to that session can be done in two, slightly different ways:

  1. By first ssh-ing to the server:

    user@host$ ssh [email protected]
    

    and then attaching to the named session:

    user@server$ tmux a -d -t tmux_session
    
  2. By ssh-ing and attaching at the same time:

    user@host$ ssh [email protected] -t tmux -a -d -t tmux_session
    

Symptoms:

Method №1 works as expected. My LANG is set to C.UTF-8, echo-ing it inside tmux_session works fine, and it's reported correctly. Unicode input of characters like "¹²³¤", works perfectly fine.

Method №2 yields a session, which is unable to display Unicode characters, beyond simple ASCII. All other characters get replaced by _ (an underscore). However when entering a special character, the character is actually entered into whatever application is running inside tmux_session, I confirmed it using editors, an IRC client, etc. When I detach and re-attach using method №1, the previously entered character is displayed correctly.

This problem when using method №2, only happens when attaching to the session with the ssh command, and it only affects the display of the characters, not the actual characters being entered.

Some of the output inside tmux is kinda broken both times, though. When I enter echo $LANG inside tmux_session using either method, I see this:

$ echo $LANG                            
cho C.UTF-8C.UTF-8

Something is garbled, for some reason the input line is (partially) repeated. I read in another post on superuser.com, that one should try by first deleting .tmux.conf. I don't have a .tmux.conf, so not having that file doesn't seem to alleviate the issue for me. In any event, $LANG being set to C.UTF-8 is correct.

This garbled output does not happen, when just ssh-ing to the server.

1
  • 1
    You should check the environment outside tmux and see if they are different between the two; at the least, ssh -t host command probably does not load profile, but there may be other differences. Checking inside the tmux session will show a mix of the configuration where the tmux server was originally started and your standard shell initialisation, which may give different results again, but less relevant ones. Commented Oct 6, 2021 at 6:33

2 Answers 2

12

You're checking the locale settings inside the tmux sessions, but not those that tmux itself receives.

server.ltd likely doesn't have AcceptEnv LANG LC_* in its sshd_config or/and you don't have SendEnv LANG LC_* in your ssh_config, so the fact that your local system and terminal is using UTF-8 as the charset is not transmitted to the remote tmux client.

You could work around it by doing:

ssh -t [email protected] "
  set -o allexport
  $(locale | grep -v '"')
  exec tmux -a -d -t tmux_session"

(assuming the local shell and the login shell of the remote user are POSIX-like)

Or just hardcode the UTF-8 locale of your choice if you know your terminal is talking in UTF-8:

ssh -t [email protected] 'exec env LANG=C.UTF-8 tmux -a -d -t tmux_session'

(a syntax understood by all shells).

1
  • Thanks, the hardcoded UTF-8 locale does it for me (as my Alpine Linux doesn't have locale installed, and I'd like to keep things minimal). I'll see if changing the *_configs will fix my issue, too. Commented Oct 6, 2021 at 12:40
3

Use tmux -u to force output of utf-8 even if $LANG is not set correctly.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.