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!
Thank you (“,)
You’re welcome!
Thanks!
I’m glad it helped you as well! Thanks for stopping by and letting me know.
Helped me too!
Great!
And thank you for making me smile
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!
Good Article.
Thank you, I appreciate it
BR,
Jeans
You’re welcome!
That was VERY useful. Thank you so much!
Great it helped you!
Thanks!
Glad to hear this helps so many people
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
Thanks for sharing how you fixed it! The down side of your fix is that you need to change it on every server you connect to. In big environments this might not be the easiest way, and so fixing it in the client is easier.
Anyway, this post became a nice collection of different ways to solve it
Oh, to clarify, I did this in the .bashrc for the local Mac OS X user. Not on the server
Oh nice!
Thank you very much!
You’re welcome!