Setting locales correctly on Mac OSX Terminal application

10 July 2012 — 49 Comments

I’ve had some trouble when using the Mac OSX Terminal app for some time now. Until today, it just gave me some annoying warnings from time to time. Like when installing an application with apt-get in Debian:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = “UTF-8″,
LANG = “en_US.UTF-8″
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

It did work, so nothing too serious. I’ve also found applications, like iotop for example, that refuses to start when LC_ALL was unset. But a quick

EXPORT LC_ALL=$LANG

made the application start, so I didn’t take the time to investigate it further. Today I run into a more serious issue that cost me quite some time to figure out.

I had stopped the pure-ftpd deamon to do some maintenance and then started it again. It did start without error, but connecting failed:

server:~# ftp ftp.server.nl
Connected to ftp.server.nl.
perl: warning: Setting locale failed.
ftp>

Nothing had changed in the ftp configuration. After some debugging and trial & error, I found out that when I started the deamon from within a shell on Ubuntu it worked, but when I started it within a shell on my MacBook, it didn’t.

When looking at the locales I found:

server:~# locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE=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=

Notice the two errors at the top. I talked to a colleague about this and he suggested looking at the Terminal app settings. There I found a setting called “Set locale environment variables on startup” which was activated. The setting is located in Preferences | Settings | Advanced. I’ve unchecked the button now as you can see in this screenshot:

When closing the Terminal app, and reopening it again, I tried again:

server:~# locale
LANG=en_US.UTF-8
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=

No more errors! I tried restarting the pure-ftpd deamon from my Terminal app and it now works as expected. Even the warnings and errors when installing applications in Debian (apt-get) are gone. In fact, it seems this is the way it is supposed to work.

Glad I’ve fixed this :-)

Update: As Reza mentions in the comments, it’s also possible to fix this problem on the server side. This is the best way to go if you want to fix this for your users. Thanks Reza!

49 responses to Setting locales correctly on Mac OSX Terminal application

  1. 

    Helped me too!

  2. 

    When encountering similar problems in the past, I used to disable in the SSH server the setting of accepting passed locale information.
    I found it a more robust approach when users with different locales could connect to the same server.
    Anyway thanks for publishing this, useful. :)

    • 

      As a sys admin that would be the way to go to solve problems for your users, indeed. If you happen to remember the exact setting, let me know and I’ll document it here. Otherwise I’ll google it myself later on.

      As a user (without access to SSH-server settings) the approach of changing a local setting is better. A lot of people seem to run into this problem these days so hopefully either one solution helps them out. Thanks for sharing!

      • 

        Good point, one solution is client side and the other server side, what applies best depends on the situation.
        About the SSH server config, standard sshd_config files found in most distros and OSX carry something like the following:

        # pass locale information
        AcceptEnv LANG LC_*

        So to make sure the locale related env variables do not get forwarded it’s enough to just comment out the AcceptEnv directive above.
        Cheers!

      • 

        I’ve had this issue for awhile and only realized now that I can do it within Terminal Preference…

        Anyways Centos sshd_config file is located: /etc/ssh/sshd_config

        and you can comment out the line as mentioned by Reza below.

  3. 

    Good Article.
    Thank you, I appreciate it :)

    BR,
    Jeans

  4. 

    That was VERY useful. Thank you so much!

  5. 

    Thanks!

  6. 

    After trying many online suggestions to fix this problem, I ended up adding the following to my ~/.bashrc:

    export LC_ALL=en_US.UTF-8

    which fixed unset locale variables, while leaving the ‘set locales at startup’ checked.

    This eliminated the warnings, since there is now a sensible LC_ALL fallback. I’m also still able to vary locale settings for terminal (+ remote) sessions.

    For multi-language users, terminal presets can be made to e.g.: login as tr_TR.UTF-8.

    I have the feeling that many users with this issue have subtle differences in the exact cause. Maybe due to updates of the locale system, updates of the remote system and even fiddling with the Mac OS X Terminal settings.

    Anyway, glad to have finaly fixed this for my environment!

    Thx to all contributers ;)

    Grtz,
    Samy

  7. 

    Thank you very much!

  8. 

    It works, thanks! Also using the iTerm app, with a similar option.

  9. 

    Reblogueó esto en Carlos Spitzery comentado:
    Nice post!

  10. 

    Uff i finally had my Vagrant ssh doesnt show the warning everytime i login to my VM…on my Mac after I unchecked that checkbox…thanks :)

  11. 

    Finally. An article that explained it accurately. Every other article made it seem to be a server side issue. It was a client/server issue. I changed my locale iterm from ascii to UTF-8, all fixed. Not to mention now all UTF-8 characters show up.

  12. 

    worked great – thank you!

  13. 

    thank you everyone!
    you saved my nerves from cracking!

  14. 

    This was a great tip, especially Riza’s way… TY.

  15. 

    Thank you

  16. 

    Big big big thx :p I was getting that with almost every git command in terminal.

  17. 

    THX!!! it was so annoying. small things can make big differences :)

  18. 

    thanks that solved it

  19. 

    Ah this was so annoying, thanks. Other websites simply just said:

    Add these two lines to .bash_profile

    export LC_CTYPE=en_US.UTF-8
    export LC_ALL=en_US.UTF-8

    Your solution is the one that worked.

    Thanks so much!

  20. 

    Thank you! :-)

  21. 

    excellent…fixed my problem with inserting accents into shell or psql cmds. Thanks much for sharing this!!

  22. 

    Eventually I found the right solution !
    Thank you
    juliusB

  23. 

    Locale identifiers are highly platform and system dependent and therefore there is no general solution to this problem. The solution that fits best can be found by reading and understanding the error messages. In the original case, Perl complained about unsupported locale settings. But it tells you that LC_ALL and LANGUAGE are unset which is perfectly okay. Likewise, LANG is set to “en_US.UTF-8″ which is also okay on a wide variety of systems. But LC_CTYPE is set to “UTF-8″ and this is wrong on most systems (with one notable exception: Mac OS X).

    Obviously the Mac OS X terminal application sets LC_CTYPE to just a character set name and not to a locale identifier. This seems to work fine on Mac OS X but not on most other operating systems.

    You can indeed avoid the problem by unchecking the “Set locale environment variables on startup” but that will leave you with all locale variables set to “C” aka “POSIX”. These locales are guaranteed to (basically!) work for all systems but you will often run into character conversion problems if you use non-UTF-8 locales.

    The correct solution is therefore to override at least the faulty LC_CTYPE setting in your shell startup file (for example “~/.bash_profile”):

    LC_CTYPE=en_US.UTF-8
    export LC_CTYPE

    You can, of course, pick other languages. And you can set other locale environment variables (LANG, LANGUAGE, LC_TIME, …) in the same manner. Just check the set of supported locales with “locale -a”. The locale identifiiers used by Mac OS X are compatible with BSD and glibc systems. Try “man locale” for more information or google for “ABOUT-NLS”.

    If your Mac OS X locale settings are not supported on a remote system, you can edit your shell startup file there in order to set your locale to something locally supported.

    Configuring the remote sshd to nuke the user locale settings looks like a rather brute and ugly solution to me.

Trackbacks and Pingbacks:

  1. My script returns gibberish text: How to get it right. Help please! - iLounge Forums - April 5, 2015

    […] It may also require you set up the Terminal to have the locales correct. I found this article: Setting locales correctly on Mac OSX Terminal application Remi Bergsma's blog That talks about it with the use of FTP, it may work for Mac OS too. Sometimes I wish I had a Mac […]

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s