Setting locales correctly on Mac OSX Terminal application

10 July 2012 — 69 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),
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


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
Connected to
perl: warning: Setting locale failed.

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

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

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!

69 responses to Setting locales correctly on Mac OSX Terminal application


    Helped me too!


    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.


        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.


    Good Article.
    Thank you, I appreciate it 🙂



    That was VERY useful. Thank you so much!




    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 😉



    Thank you very much!


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


    Reblogueó esto en Carlos Spitzery comentado:
    Nice post!


    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 🙂


    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.


    worked great – thank you!


    thank you everyone!
    you saved my nerves from cracking!


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


    Thank you


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


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


    thanks that solved it


    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!


    Thank you! 🙂


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


    Eventually I found the right solution !
    Thank you


    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”):

    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.


    Note 1: This comment is not directly related to ONLY Terminal and encoding, but also encoding on different GUI on MacOS.

    On my MacBook (MacOS 10.10.3.) I use 3 language US, PL (Polish – Pro), UA (Ukrainian – PC). Now I do my research regarding encoding (potential issue).

    Note 2:
    Time ago, when I just bought MacBook, I tried to recreated standard Input Source “Ukrainian” into my variant by software Ukelele. It was working fine, but then I realized I have encoding issue with MyHeritage FamilyTreeBuilder. And to fix it, I just switched to normal “Ukrainian PC” input source, and everything was visually works fine.
    This note is to inform you what I was doing time ago related to Languages/Encoding.

    But recently, I exported GEDCOM file (simple text file with specific coding syntax) and inside of it there is mention of encoding utf-8, but GEDMATCH.COM after importing the file, shows my informattion in very wrong encoding. Potentially it’s problem (I keep in touch with their support).

    Anyway, I started worrying about my UTF-8-like MacOS input source and googled for command “locale”. In terminal I have “Set locale environment variables on startup” checked. Command locale gives me this:


    So, @Remi_Bergsma I googled your blog entry, and here is the question:

    Should I worry that I have many “C”? Should I manually via .bash_profile file set explicitly UTF-8 to avoid possible character changing issues as mentioned by @Guido_Flohr?


    In iterm2, go to: Profiles -> Terminal and uncheck: “Set locale variables automatically”.
    Restart iterm afterwards.


    Had this problem trying importing matplotlib in python. It works now. Thanks a lot


    A couple of years later, and this is till very useful. Thanks!


    You saved my life! i had a problem importing py seaborn library. I had tried with conda, pip and no luck, in both 3.5 and 2.7. when i came across your post, and i deselected the tick now works like a charm.
    Many thanks!


    Still works, thank you very much!


    Thank you very much, I was driving crazy with that


    Very useful, Thank you


    Thank you sooo much! It’s just 7:30am, but you made my day!


    Thank you sooo much! It’s just 7:30am but you made my day!


    Perfect to me. Clap.


    yes, it’s 2019 – and this article saved me today! many thanks

    HappyOSXuser 21 March 2019 at 22:47

    Great tutorial and it works like a charm. Keep up the good work! 🙂

    Guilherme Caeiro Dias 3 March 2020 at 17:44

    I just bought a new MacBook Pro. I set all definitions to work on the remote server (where I was working before with my 10yo MacBook Pro). But when I logged in for the first time I got the following error:

    -bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory

    2020 and this post saved me. It works like a charm.



    thank you so much =)


    Thanks a lot. Was bothered by this for past few days.

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 […]

  2. Mac i problemy z locale w terminalu – HOWTO – Pomiędzy bitami - July 23, 2019

    […] Pierwsze rozwiązanie, które znalazłem, wyglądało elegancko i nawet tłumaczyłoby, czemu nie działa skoro locales są ustawione. Niestety, po włączeniu i otwarciu nowych zakładek w terminalu, a nawet restarcie terminala okazało się, że… nie działa. Teraz widzę, że rozwiązanie jest stare, z 2012, wtedy mi umknęło. […]

  3. Terminal Show Multiple Languages – - February 26, 2020

    […] Otherwise, it will use ISO-8859-1. A Mac problem resolved. […]

Leave a Reply to Roger Cancel reply

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

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

Facebook photo

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

Connecting to %s