2

I want to be able to SSH to a remote host and restore a screen session with one command. Both hosts use UTF-8 locale. My problem is that then, inside the screen session, characters are encoded twice.

As stated in other related questions, I need to pass the -t option to ssh command in order to allocate a pseudo-tty for an interactive session:

https://stackoverflow.com/questions/474967/automatically-or-more-easily-reconnect-to-a-screen-session-after-network-inter

Thus the command I use is ssh -t remotehost screen -dr. When I restore screen this way, the characters I send from the keyboard are encoded twice, and the characters I receive from the remote host are decoded twice:

localhost % ssh -t remotehost screen -dr
remotehost % echo ä | hexdump -C
0000000 c3 83 c2 a4 0a
0000005

This doesn't happen if I first connect to the remote host and then restore screen:

localhost % ssh remotehost
remotehost % screen -dr
remotehost % echo ä | hexdump -C
0000000 c3 a4 0a
0000003

What I mean by "characters are encoded twice" is that normally I see the same output if I type:

localhost % echo ä | iconv -f ISO-8859-1 -t UTF-8 | hexdump -C
00000000  c3 83 c2 a4 0a
00000005

The pseudo-tty allocation alone doesn't cause the problem. I've tried:

localhost % ssh -t remotehost /bin/zsh
remotehost % screen -dr
remotehost % echo ä | hexdump -C
0000000 c3 a4 0a
0000003
  • 1
    You need to tell the screen that you're going to attach to the session that your locale is UTF-8. ssh -t remotehost LANG=fi_FI.UTF-8 screen -dt – Stéphane Chazelas Sep 11 '14 at 6:54
  • Nice, that did the trick! Thanks a lot. (There's a typo: screen -dr, not screen -dt) – Seppo Enarvi Sep 11 '14 at 8:16
3

That suggests the screen that you're attaching your session to thinks your terminal is not in UTF-8.

It thinks for instance (if it assumes the charset is iso-8859-1 instead) that 0xc3 coming from the terminal device means a Ã.

The screen session, however is running in UTF-8 (screen is a terminal emulator that can be attached to different types of terminals).

So, when typing ä, you're sending 0xc3 0xa4. screen understands that you're typing two characters (Ã and ¤). It needs to convert them to their UTF-8 equivalent.

On display, those UTF-8 characters are converted to their iso-8859-1 equivalent which is why you're seeing ä and not ä.

You need to tell screen that your terminal is UTF-8.

Usually, it's enough to set the locale to a UTF-8 one.

Most ssh deployments pass the locale information from the client to the remote command. If your locale on the client is a UTF-8 one, then either ssh doesn't pass the locale environment variables, or sshd doesn't accept them, or the locale on the client side is not one of the supported ones on the server, or your ~/.bashrc on the server somehow overrides it.

In any case, doing:

ssh -t remotehost LANG=fi_FI.UTF-8 screen -dr

(making sure fi_FI.UTF-8 is indeed a locale supported on the remote host, see locale -a to check) should fix it.

  • Thanks for the extremely informative answer, which helped me to figure out what's wrong. Turned out my environment is not set properly for non-interactive shell sessions. – Seppo Enarvi Sep 12 '14 at 5:35
1

screen has an option for running in UTF-8 mode:

   -U   Run screen in UTF-8 mode. 
        This option tells screen that your terminal sends and
        understands UTF-8 encoded characters.
        It also sets the default encoding
        for new windows to `utf8'.
  • This works as well. Is there any difference compared to setting LANG environment variable as in the other answer? What is the purpose of the window encoding setting? LANG tells the encoding of the terminal and window encoding is the encoding of the remote host? – Seppo Enarvi Sep 12 '14 at 5:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.