How to fix a locale setting warning from Perl

B

48

839

When I run perl, I get the warning:

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").

How do I fix it?

Banian answered 23/3, 2010 at 12:27 Comment(5)

What happened when you checked the locale settings like the error message told you? – Vivian 23/3, 2010 at 17:13

instead of installing the locale, you can also change the locale. On my Ubuntu box, this is done for one user by editing ~/.pam_environment – Lawry 8/6, 2014 at 12:34

On my ODROID-C1 running Ubuntu the issue was indeed the ~/.pam_environment file. Some of the variables were es_US.UTF-8 instead of en_US.UTF-8. Thank you. – Intussuscept 18/2, 2015 at 13:12

I got this on Cygwin\Babun. Only a reinstall of perl fixed it. – Aeciospore 16/9, 2016 at 20:12

If you are here in 2023, it probably means you are SSH:ing into a Raspbian device. – Yore 5/3 at 9:48

S

553

Your OS doesn't know about en_US.UTF-8.

You didn't mention a specific platform, but I can reproduce your problem:

% uname -a
OSF1 hunter2 V5.1 2650 alpha
% perl -e exit
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
    LC_ALL = (unset),
    LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

My guess is you used ssh to connect to this older host from a newer desktop machine. It's common for /etc/ssh/sshd_config to contain

AcceptEnv LANG LC_*

which allows clients to propagate the values of those environment variables into new sessions.

The warning gives you a hint about how to squelch it if you don't require the full-up locale:

% env LANG=C perl -e exit
%

or with Bash:

$ LANG=C perl -e exit
$

For a permanent fix, choose one of

On the older host, set the LANG environment variable in your shell's initialization file.
Modify your environment on the client side, e.g., rather than ssh hunter2, use the command LANG=C ssh hunter2.
If you have administrator rights, stop ssh from sending the environment variables by commenting out the SendEnv LANG LC_* line in the local /etc/ssh/ssh_config file. (Thanks to this answer. See Bug 1285 for OpenSSH for more.)

Selfless answered 24/3, 2010 at 18:50 Comment(13)

Thanks! I had this error message when connecting with git to my server. After adding de_CH.UTF-8 (was not supported there but used locally) with dpkg-reconfigure locales the message is gone. – Tycho 28/10, 2012 at 20:22

I had this issue for ages,... removing "AcceptEnv LANG LC_*" from sshd_config finally resolved it. Thanks for the hint! – Tunicate 11/1, 2013 at 19:55

@Greg Bacon, Wouldn't there also be cases in which you would want to set the environment variables system wide, for example by creating an /etc/environment file? help.ubuntu.com/community/… – Quintonquintuple 8/2, 2014 at 11:5

@HermannIngjaldsson, at least on Ubuntu (12.10), there was no need to reboot the server (after removing "AcceptEnv LANG LC_*"). I just reloaded ssh config: service ssh reload, which takes a fraction of a second, and doesn't even cause the current ssh session to terminate. – Himelman 6/4, 2014 at 11:21

append 'export LC_ALL=C' then 'source ~/.bashrc' at client system solve the problem. – Henryk 15/7, 2014 at 1:56

Another option for folks who use git and get this error when interacting with a remote is to comment out SendEnv LANG LC_* in /etc/ssh/ssh_config on the client machine. – Socalled 8/6, 2015 at 1:42

or try fix 3.: Add the locales which are typically set by ssh clients in /etc/locale.gen, then run dpkg-reconfigure locales. If you know which locales are affected, this might be the least invasive measure. – Welt 3/12, 2015 at 12:38

commenting out "AcceptEnv LANG LC_*" in sshd_config wiped my bash history on the host :( so think before doing that people! – Corsica 9/8, 2016 at 23:48

Thank you from 2017! Commented sshd_config with no problems... Was very confused where pt-BR locale was coming from on that server! – Postobit 7/3, 2017 at 16:30

Fellow Gentoo users: I followed the advice of commenting out the SendEnv line in /etc/ssh/ssh_config. See also the (polarized) discussion at bugs.gentoo.org/367017 . – Hamper 16/7, 2019 at 0:29

Instead of changing the global ssh config file you can also add SetEnv LANG=C in ~/.ssh/config for the host that complains. – Pinhead 8/6, 2020 at 12:56

I'm confused about fix 1. (editing .bashrc on the host did not work in my case). How is this supposed to work, if the client locale env variables are still forwarded by the ssh client? – Moya 7/9, 2021 at 14:4

You can also alias permanent solution number 2: alias ssh='(){ LANG=C ssh $@ }' in your .zshrc – Nickinickie 10/10, 2022 at 18:16

F

611

Here is how to solve it on Mac OS X v10.7 (Lion) or Cygwin (Windows 10):

Add the following lines to your bashrc or bash_profile file on the host machine:

# Setting for the new UTF-8 terminal support in Lion
export LC_CTYPE=en_US.UTF-8
export LC_ALL=en_US.UTF-8

If you are using Z shell (zsh), edit file zshrc:

# Setting for the new UTF-8 terminal support in Lion
LC_CTYPE=en_US.UTF-8
LC_ALL=en_US.UTF-8

Flunky answered 14/9, 2011 at 9:9 Comment(12)

Thanks, I've search a solution for this problem for a long time, and I always thought it's a problem in my Ubuntu server configuration, and it seemed that there was no solution that helped (all that dkpg-reconfigure stuff( – Giraud 20/4, 2012 at 14:46

Because LC_ALL overwrites all other variables, I’d rather set LANG=de_AT.UTF-8 and individual variables like LC_MESSAGES=en_US.UTF-8. If a variable is not set it falls back to LANG. You can also eg. unset LC_CTYPE to force it fall back to LANG. – Deluge 4/3, 2013 at 21:4

Placing those lines in .bashrc didn't work, but bash_profile solved it! I had to create the file. – Protactinium 10/5, 2013 at 8:32

Putting these lines in ~/.bashrc solved it for me... then must reload using source ~/.bashrc... Thnks <3 – Franci 2/8, 2013 at 12:22

and i got this on my ubuntu: "sudo: export: command not found " – Abject 25/11, 2013 at 15:36

Where is the bash_profile script located? or where to I put it once I'm in terminal on Mac Mavericks? bashrc, .bashrc. bash_profile, or .bash_profile are not in my home directory. Or am I supposed to edit my remove linux server (running Cent)S) – Gunboat 4/9, 2014 at 5:15

awesome, thanks for this. I encountered this problem inside and ubuntu vm running on mavericks, but because I was sshed in with an OSX terminal this was the fix. – Jola 26/2, 2015 at 20:14

This fixed the problem for Ubuntu 14 as well. I think my remote machine picked up the locate from my desktop when I SSHed and set the wrong locale. Remote is US machine while my desktop is AU – Dome 26/5, 2015 at 13:21

Thanks, this worked fine on ZSH and the oh-my-zsh plugin under Mac OS X El Capitan, at the bottom of ~/.zshrc : LC_CTYPE=en_US.UTF-8 LC_ALL=en_US.UTF-8 – Marva 9/11, 2015 at 9:14

@Abject If you are connecting to server, it is possible that you do so as 'root' user. You can confirm it by running "echo $USER". If that is the case, you need to skip 'sudo', as you don't need it. – Herschel 7/8, 2016 at 13:2

As bash_profile is only read by bash for login shells, so this solution can fail for a wide variety of reasons (not a login shell, not using bash, maybe its not run from a shell at all). It is better to change the settings in /etc/default/locale, which can be done manually or using update-locale. – Transistor 3/3, 2018 at 21:7

-bash: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8) – Pet 6/1, 2023 at 23:38

S

553