4

I have configured my terminal on OSX to show emoji properly. When I open up a terminal I can type and see emoji properly. My locale settings for OSX are shown below. When I start a tmux session it works fine as well.

However, when I start up an ssh session to my Ubuntu server emoji is shown as a strange digit. Locale settings for Ubuntu ssh session are also shown below.

I am wondering why this is and how I can fix it. I am using Droid Sans Mono for Powerline as the font in my terminal. OSX version is El Capitan and the version of Ubuntu on my server is 14.04 LTS.

OSX locale

dino :: locale               
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"

Linux locale (via ssh session)

testarossa :: ~ %locale              
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

What an emoji looks like on local session in OSX

enter image description here

What the same string looks like on a remote session on my Ubuntu machine

enter image description here

Improve this question
0

1 Answer 1

Reset to default
3

The value of TERM is irrelevant. What does matter is the terminal emulator (and also the version of glibc). See for example my comments in Debian #790847:

Interestingly, the lynx package in Fedora22 works
(passably with vte
 -- none of the other terminals display Emoji
 -- no need for a list).

while (I cannot verify at the moment), Ubuntu 14.04 is likely old enough that the problem which I noted later, in glibc is relevant:

Further checking in Debian/testing shows me that wcwidth() is returning -1's
for these values (which is incorrect, it should return 1's).  Lynx is behaving
correctly for this case -- it has no way to tell that the characters "should"
print as expected.
Improve this answer

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.