I upgraded to 10.7 today, only to find that my IRC client (Irssi running in a screen on a remote server) suddenly had decided that it hated any and all non-ASCII characters, replacing them with ?’s instead. In the local terminal everything worked just fine. I use UTF-8 as the terminal charset on both the server and in the OS X terminal, and everything had worked just fine prior to the upgrade, both on the Mac, on my Windows box (using PuTTY) and on various other Unix machines.
I eventually traced the problem to the OS X built-in ssh client (/usr/bin/ssh), which for some reason badly mishandles UTF-8 in Lion. There are two three possible workarounds:
- install a different SSH client (OpenSSH installed via MacPorts is a good alternative), or
- do everything on the remote server in a screen launched with the -U flag. The defencoding and defutf8 flags in your screenrc will not help.
- new solution, reported to work but not tested by me: edit /etc/ssh_config and remove the LC_* part from the line that says SendEnv LANG LC_*.
A very late update, March 2012: the third solution is probably the best. Either remove the LC_* part, or comment out the entire line. The comments on this article have some more relevant information about why this is the correct solution; comments #21 and #22 are particularly helpful. Thank you, internet!
Comments (26)
It works for me. Mostly the same test case, ssh to remote server, irssi, and utf-8 displays fine. Maybe you need a new screen session?
The remote server is running 10.5 Leopard, if that matters.
Can you enter UTF-8 characters outside the screen though? Literally all of my OS X-using friends have the same issue, so it’s not just me.
I can, both on my OS X server and on my Ubuntu one. Here’s a screenshot: http://inb4.us/6bgC
Funky.
Is that zsh? Because that worked for me too for some reason. bash does not, and nor does zsh inside a screen launched without -U.
bash on both machines.
That’s really odd. For me, trying to input any non-ASCII character in bash just makes it ring a bell. Before Lion this used to work just fine. I’ve never had to launch screen with -U before either.
Further investigation reveals that for some reason LC_CTYPE was set to UTF-8 instead of en_US.UTF-8 (and in some cases on friends’ machines, not set at all). Changing that setting makes things magically work.
Further further investigation: the above works on Ubuntu, but on an older Debian machine literally everything in a screen is ZOMG ULTRA LASER BORKED no matter what I try.
The same issue for me. The temporary cure is to execute ‘export LC_ALL=en_US.UTF-8′ before ssh
Could it be that the SSH client sends the LANG and LC_* to the server? I had a similar problem on Linux (server and client, OpenSSH). Removing SendEnv LANG LC_* from the ssh_config file fixed it.
The server has a similar setting: AcceptEnv LANG LC_*
It didn’t broke my terminal / ssh / screen / irssi combination. Maybe it gets broken only on a certain hardware (hint: I have MBP, what do you have?). My friend has the same problem and he is running on Air.
MBP here too. I think it’s dependent on the target system though, not on the hardware on the Mac.
Hi guys, the same problem here – MacMini connecting to Ubuntu server 10.04. The first connection after Mac restart is ok, the rest broken. From win machine (putty portable) works ok, though.
ssh and Lion problems here, too (MBP).
ssh user@site.com
PTY allocation request failed on channel 0
Works fine on all other machines/SSH clients. GARBAGE.
Looks like the problem is related to Terminal.app and not SSH – it works fine in iTerm.
Also, disabling the forwarding of LC variables in /etc/ssh_config on the Lion client seems to fix this issue.
hi, I think my problem is related to yours.
On a OSx 10.6 laptop using ssh to another machine gives me a colored screen. Doing ssh on my OSx 10.7 laptop to the same machine gives me black and white screen and also a lot of key combinations behave differently.
I tried the suggestions you mentioned but it does not solve this situation.
I compared /etc/ssh_config, locale and locale -a on both machines and they are the same. Do you have any suggestions?
thanks
I have the same issue, but with SSH/iOS/weechat.
The third solution worked for me. From Mac OS X 10.7 ssh to Ubuntu Server 10.10.
Thanks!
Same here… and the 3rd solution works! Thanks for sharing!
Actually the real problem that’s causing this is that Mac OS 10.7 sets totally non-standard locale values, at least when you tweak some of the formats in SysPrefs/Language&Text as I did.
If you type “locale” on your Mac terminal you should see pretty much the same as on other Unices (e.g. lots of en_US.UTF-8s if you prefer US English), but you don’t. If these garbled settings get transferred to other Unix hosts by the SendEnv option they naturally do not know what’s going on.
So if you want to fix it cleanly to allow for sshing to all kinds of remote hosts, including those with older character sets, put the following
lines in your ~/.bash_profile on your Mac client machine.
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
Remote machine uses UTF8 locale, Terminal profile encoding is ISO Latin 1. When I start mc in the remote shell, shows crappy half tablescreen (with expected weird characters) but Terminal generates a huge load on my MBP. Have to force quitting.
Changing to UTF8 in Terminal before starting mc solves this but it was working fine on SL :\
Very annoying cause I have to work on several remote machines with vary locales, and I have to keep in mind this not to kill my Terminal process.
iTerm2?
I’ve seen a similar problem when SSHing into my cloud servers and editing text files with nano or vim. At first I thought it was AWS but for the problem is OSX terminal. I’ve replaced it with iTerm2, which is just plain better anyways.
If you are using ssh v 5.6 or newer, you can also use:
ssh -T usr@url
The “-T” fixes it….
Hi! Thank you, the third workaround solved the problem. I have Mac OS X Lion and IRC shell (screen + irssi) running on Ubuntu 12.04.
Cheers!
Thank you, the /etc/wtf solution worked perfectly!
Trackback/Pingback (1)
[…] related thread on this topic: http://mod16.org/hurfdurf/?p=189 Answered by Jonatan […]