How to fix a locale setting warning from Perl

Question

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?

What happened when you checked the locale settings like the error message told you? — brian d foy, Mar 23 '10 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` — Janus Troelsen, Jun 08 '14 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. — f1vefour, Feb 18 '15 at 13:12
I got this on Cygwin\Babun. Only a reinstall of perl fixed it. — Lucas Soares, Sep 16 '16 at 20:12

score 593 · Answer 1 · edited Dec 04 '20 at 18:18

593

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

edited Dec 04 '20 at 18:18

Peter Mortensen

30,738
21
105
131

answered Sep 14 '11 at 09:09

Allen Bargi

14,674
9
59
58

8

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( – Teemu Kurppa Apr 20 '12 at 14:46
8

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`. – David Mar 04 '13 at 21:04
4

Placing those lines in .bashrc didn't work, but bash_profile solved it! I had to create the file. – john-jones May 10 '13 at 08:32
8

Putting these lines in `~/.bashrc` solved it for me... then must reload using `source ~/.bashrc`... Thnks <3 – Enissay Aug 02 '13 at 12:22
and i got this on my ubuntu: "sudo: export: command not found " – GusDeCooL Nov 25 '13 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) – user658182 Sep 04 '14 at 05: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. – bcr Feb 26 '15 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 – Ganesh Krishnan May 26 '15 at 13:21
5

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 – Valerio Schiavoni Nov 09 '15 at 09:14
@GusDeCooL 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. – Rafal Aug 07 '16 at 13:02
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`. – Nuvanda Mar 03 '18 at 21:07
`-bash: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8)` – Aaron Franke Jan 06 '23 at 23:38

score 543 · Accepted Answer · edited Dec 04 '20 at 18:15

543

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

edited Dec 04 '20 at 18:15

Peter Mortensen

30,738
21
105
131

answered Mar 24 '10 at 18:50

Greg Bacon

134,834
32
188
245

30

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. – Simon A. Eugster Oct 28 '12 at 20:22
96

I had this issue for ages,... removing "AcceptEnv LANG LC_*" from sshd_config finally resolved it. Thanks for the hint! – madc Jan 11 '13 at 19:55
2

@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? https://help.ubuntu.com/community/EnvironmentVariables#System-wide_environment_variables – fraxture Feb 08 '14 at 11:05
29

@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. – noamtm Apr 06 '14 at 11:21
5

append 'export LC_ALL=C' then 'source ~/.bashrc' at client system solve the problem. – EffectiveMatrix Jul 15 '14 at 01:56
2

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. – broetchen Jun 08 '15 at 01:42
2

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. – quazgar Dec 03 '15 at 12:38
2

commenting out "AcceptEnv LANG LC_*" in sshd_config wiped my bash history on the host :( so think before doing that people! – gevra Aug 09 '16 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! – Hugo Mar 07 '17 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 https://bugs.gentoo.org/367017 . – Pistos Jul 16 '19 at 00:29
1

Instead of changing the global ssh config file you can also add `SetEnv LANG=C` in `~/.ssh/config` for the host that complains. – tectux Jun 08 '20 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? – Sébastien Sep 07 '21 at 14:04
You can also alias permanent solution number 2: `alias ssh='(){ LANG=C ssh $@ }'` in your `.zshrc` – Nils Oct 10 '22 at 18:16

score 256 · Answer 3 · edited Sep 03 '17 at 21:27

256

If you are creating a rootfs using debootstrap you will need to generate the locales. You can do this by running:

# (optional) enable missing locales
sudo nano /etc/locale.gen

# then regenerate
sudo locale-gen

This tip comes from, https://help.ubuntu.com/community/Xen

edited Sep 03 '17 at 21:27

kritzikratzi

19,662
1
29
40

answered Mar 15 '12 at 20:28

Marc

2,886
1
15
12

9

locale-gen does not take any arguments (in Debian stable at least). Instead, edit /etc/locale.gen to uncomment the locales you want, then run sudo locale-gen – Sam Watkins Feb 06 '14 at 02:23
7

On Debian you may need to do `$ echo en_US UTF-8 >> /etc/locale.gen` first. – akhmed Nov 24 '15 at 02:44
2

On Gentoo (at least), `locale-gen` does not take arguments. It reads from `/etc/locale.gen`. – Pistos Sep 07 '16 at 03:41
some distributions don't use a configuration file and need the following, ```sudo locale-gen en_US.UTF-8``` – Marc Sep 05 '17 at 16:06
1

@akhmed You should only need to uncomment the line `# en_US.UTF-8 UTF-8`. – Franklin Yu Aug 03 '18 at 04:02
What is "rootfs"? [tmpfs](https://en.wikipedia.org/wiki/Tmpfs#Linux)? – Peter Mortensen Dec 04 '20 at 18:24
editing /etc/locale.gen uncommenting da_DK.UTF-8 and run sudo locale.gen did - after quite some time - the job. Thanks ! Newbee! – mortenlund May 28 '22 at 21:25
I think this is also the case when creating an image using `rpi-imager` and specifying the locale in settings – bb1950328 Jul 02 '22 at 16:17

score 181 · Answer 4 · edited Dec 04 '19 at 12:52

181

Use:

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

It works for Debian. I don't know why - but locale-gen had not results.

Important! It's a temporary solution. It has to be run for each session.

edited Dec 04 '19 at 12:52

ᴍᴇʜᴏᴠ

4,804
4
44
57

answered Mar 17 '14 at 13:25

artemn

1,929
1
12
7

18

This one worked for me. I just put it into my `.bashrc` file. – Anirudh Ramanathan Jun 08 '14 at 16:08
3

Worked for me too. I only had to set the two settings (LANGUAGE and LC_ALL) that appeared unset in the Perl warnings – laurent Dec 15 '14 at 14:27
2

On Debian, `local-gen` only processes locales that are uncommented in `/etc/local.gen`. You may need to do `echo en_US UTF-8 >> /etc/locale.gen` first. – akhmed Nov 24 '15 at 02:45
1

LC_**C**TYPE may be? – mixel Jul 24 '16 at 13:59
should be `LC_CTYPE` – ᴍᴇʜᴏᴠ Dec 04 '19 at 12:52

score 168 · Answer 5 · edited Mar 23 '10 at 15:24

168

This generally means you haven't properly set up locales on your Linux box.

On Debian or Ubuntu, that means you need to do

$ sudo locale-gen
$ sudo dpkg-reconfigure locales

For macOS & Mac OS X users only

I was getting the same warning while using Git

To resolve this warning Uncheck the Set locale environment variable on startup option and restart your terminal. Below screen shot represents my terminal settings.

edited Jun 20 '20 at 09:12

Community

1
1

answered Dec 17 '13 at 06:33

Inder Kumar Rathore

39,458
17
135
184

4

I tried all the others but this one did it for me. I use iTerm and it has the same character encoding option. – Michael Morrison Apr 25 '14 at 03:26
2

Unfortunately this breaks ZSH (tabbing stopped working) – Christian May 17 '15 at 08:07
1

This totally does the trick for Mac OS. By the way, this starting happening to me right after upgraded to macOS Sierra. And this did fix this issue for me. – Paulo Malvar Oct 12 '16 at 04:48
1

this fixed my problem. it started to happen to me, after updating to Mac OS X High Sierra from Sierra. – Lucian Irimie Jan 12 '18 at 10:49
2

Yup. I use iTerm. Wiping problem Mac system settings fixed some Mac crashes, but caused this issue when running Perl on my long-stable CentOS server, connected via Mac / iTerm. Disabling the automatic locale set on connect fixed it. iTerm -> Preferences ->Profiles->Terminal->Environment->Set locale variables automatically. Uncheck this, and restart iTerm. – joe Sep 11 '21 at 16:43

score 41 · Answer 7 · edited Jan 08 '16 at 23:11

41

It is simple fix in Ubuntu. You have to generate the Locales from scratch, running the following commands from the command line:

sudo locale-gen en_US en_US.UTF-8
sudo dpkg-reconfigure locales

This should create the locales and then re-configure them.

edited Jan 08 '16 at 23:11

Peter Mortensen

30,738
21
105
131

answered Dec 31 '14 at 17:40

jfreak53

2,239
7
37
53

This worked fine to me even using `pt_BR pt_BR.UTF-8` - Thanks. – Marcos Freitas Oct 23 '17 at 21:31

score 37 · Answer 8 · edited Dec 04 '19 at 12:53

37

Adding the following to /etc/environment fixed the problem for me on Debian and Ubuntu (of course, modify to match the locale you want to use):

LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8

edited Dec 04 '19 at 12:53

ᴍᴇʜᴏᴠ

4,804
4
44
57

answered Jan 26 '14 at 12:09

joscarsson

4,789
4
35
43

7

.. I got a warning saying setting locale in `/etc/environment` is deprecated and should instead be set in `/etc/default/locale`. Both seems to work for now. – joscarsson Feb 19 '14 at 22:17
1

should be `LC_CTYPE` – ᴍᴇʜᴏᴠ Dec 04 '19 at 12:51

warvariuc · Answer 9 · 2017-02-23T16:42:05.263

I am now using this:

$ cat /etc/environment
...
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8

Then log out of SSH session and log in again.

Old answer:

Only this helped me:

$ locale
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=ru_RU.UTF-8
LC_TIME=ru_RU.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=ru_RU.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=ru_RU.UTF-8
LC_NAME=ru_RU.UTF-8
LC_ADDRESS=ru_RU.UTF-8
LC_TELEPHONE=ru_RU.UTF-8
LC_MEASUREMENT=ru_RU.UTF-8
LC_IDENTIFICATION=ru_RU.UTF-8
LC_ALL=

$ sudo su

# export LANGUAGE=en_US.UTF-8
# export LANG=en_US.UTF-8
# export LC_ALL=en_US.UTF-8

# locale-gen en_US.UTF-8
Generating locales...
  en_US.UTF-8... up-to-date
Generation complete.

# dpkg-reconfigure locales
Generating locales...
  en_AG.UTF-8... done
  en_AU.UTF-8... done
  en_BW.UTF-8... done
  en_CA.UTF-8... done
  en_DK.UTF-8... done
  en_GB.UTF-8... done
  en_HK.UTF-8... done
  en_IE.UTF-8... done
  en_IN.UTF-8... done
  en_NG.UTF-8... done
  en_NZ.UTF-8... done
  en_PH.UTF-8... done
  en_SG.UTF-8... done
  en_US.UTF-8... up-to-date
  en_ZA.UTF-8... done
  en_ZM.UTF-8... done
  en_ZW.UTF-8... done
Generation complete.

# exit

$ locale
LANG=en_US.UTF-8
LANGUAGE=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=en_US.UTF-8

This worked fine for me on Ubuntu 15.04, thanks a lot. – Goke Obasa Jun 21 '16 at 06:12 — Goke Obasa, Jun 21 '16 at 06:12

score 25 · Answer 10 · edited Dec 04 '20 at 18:27

25

On Debian, after much searching, this did the trick.

First:

sudo apt-get purge locales

Then:

sudo aptitude install locales

And the famous:

sudo dpkg-reconfigure locales

This rids the system of locales, then re-installs locales and downgrades libc6 from 2.19 to 2.13 which is the issue. Then it configures locales again.

edited Dec 04 '20 at 18:27

Peter Mortensen

30,738
21
105
131

answered Sep 18 '14 at 05:34

tkjef

704
7
17

5

`dpkg-reconfigure locales` is all that is needed. `sudo` if you are a sudo type guy, or do it as root. Then select your locale according to what you have in your shell environment. – mknaf Oct 01 '14 at 13:36
7

dpkg-reconfigure locales SHOULD be all that is needed. After you have tried that 100 times and looked around the internet and that's all you've seen and the problem still won't resolve itself try the above. Then come back and upvote this. :) – tkjef Oct 01 '14 at 14:42
If your system is hosed to the point where purging and reinstalling a package solves something, you probably have other, more serious problems. – tripleee May 01 '23 at 11:29

score 22 · Answer 11 · edited Dec 04 '20 at 18:46

22

We will set locales that are not unset after reboot.

First open the Bash file and edit it:

nano .bashrc

Add these lines to the file:

export LC_ALL="en_US.UTF-8"
export LANG="en_US.UTF-8"
export LANGUAGE="en_US.UTF-8"

Activate the change by reloading Bash:

source ~/.bashrc

Test results:

locale

edited Dec 04 '20 at 18:46

Peter Mortensen

30,738
21
105
131

answered Feb 02 '19 at 00:38

Alouani Younes

948
9
17

The only one that works for me, Raspbian and ubuntu server 16.04 :) – Liso Apr 26 '20 at 05:53
If you are looking for a copy/paste answer, this _might_ work. What exactly works depends on which locales are actually installed. Anyway, this is a duplicate of older answers with essentially the same solution. – tripleee May 01 '23 at 11:25

score 13 · Answer 12 · edited Dec 04 '20 at 18:43

13

For Ubuntu use this,

#export LANGUAGE=en_US.UTF-8
#export LC_ALL=en_US.UTF-8
#export LANG=en_US.UTF-8
#export LC_TYPE=en_US.UTF-8

It worked for me.

edited Dec 04 '20 at 18:43

Peter Mortensen

30,738
21
105
131

answered Apr 12 '18 at 12:59

Amjith

445
5
15

It also worked for me, by removing all content in file `/etc/default/locale` and putting only the definition of the vars (removing the word export) and restarting the server – Edenshaw Jan 15 '19 at 16:54
... and not for me. "worked for you" generally is not a good enough criterion. I suggest trying what I post below – dotbit Oct 10 '20 at 22:11

score 13 · Answer 13 · edited May 10 '23 at 06:52

13

For Debian users, I have this problem after modifying my locale to change machine's language. This is what I did:

Modify .bashrc:

export LANG=fr_FR.UTF-8
export LC_ALL=fr_FR.UTF-8

Uncomment line fr_FR.UTF-8 in file /etc/locale.gen -> sudo locale-gen to generate the missing package
sudo update-locale
sudo dpkg-reconfigure locales to configure my locale to fr_FR.UTF-8

Add extra lines to the /etc/default/locale file:

LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8
LC_TYPE=en_US.UTF-8

Reboot my computer and everything works fine

edited May 10 '23 at 06:52

tripleee

175,061
34
275
318

answered Jul 10 '19 at 08:38

Lala

347
2
7

Sometimes 5. is the only thing that works. Still kinda puzzled by this behaviour. – binaryanomaly May 03 '21 at 09:20

score 12 · Answer 14 · edited Jan 08 '16 at 23:18

12

If you use Mac OS X v10.10 (Yosemite) or above to connect in your server Linux, you can try these steps.

Keep your file /etc/ssh/sshd-config original

Put on your ~/.bash_profile

export LANG="en_US"
export LC_ALL=$LANG.UTF-8

Run
```
dpkg-reconfigure locales
```
And select "en_US.UTF-8"

edited Jan 08 '16 at 23:18

Peter Mortensen

30,738
21
105
131

answered Dec 15 '15 at 23:33

dsandrade

576
5
9

score 11 · Answer 15 · edited Dec 04 '20 at 18:26

11

sudo nano /etc/locale.gen

Uncomment the locales you want to use (e.g. en_US.UTF-8 UTF-8):

Then run:

sudo /usr/sbin/locale-gen

Source: Configuring Locales

edited Dec 04 '20 at 18:26

Peter Mortensen

30,738
21
105
131

answered Jun 16 '14 at 13:46

Thomas Jensen

2,635
25
38

The company I work for in USA hosts a git server that has international customers. The GB crowd complained that their git clones over ssh would have problems due to locale differences. This applied on the server fixed this issue for them. – Therealstubot Sep 13 '18 at 19:04

glarrain · Answer 16 · 2015-12-14T17:38:53.063

10

You need to configure locale appropriately in /etc/default/locale, logout, login, and then run the regular commands

root@host:~# echo -e 'LANG=en_US.UTF-8\nLC_ALL=en_US.UTF-8' > /etc/default/locale
root@host:~# exit
local-user@local:~$ ssh root@host
root@host:~# locale-gen en_US.UTF-8
root@host:~# dpkg-reconfigure locales

edited Dec 14 '15 at 17:38

answered Apr 09 '14 at 21:24

glarrain

8,031
7
31
44

4

these steps worked for me (Ubuntu server 14.04). the main point was to logout and login again. – liberborn Dec 06 '15 at 18:13

bogdanvlviv · Answer 17 · 2016-09-28T14:01:16.910

10

perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_ALL to default locale: No such file or directory

Solution:

Try this (uk_UA.UTF-8 is my current locale. Write your locale, for example en_US.UTF-8 !)

sudo locale-gen uk_UA.UTF-8

and this.

sudo dpkg-reconfigure locales

edited Sep 28 '16 at 14:01

answered Feb 24 '16 at 19:22

bogdanvlviv

149
2
5

Thank you this solved my problem, after doing this and reinstalling. – madprops Sep 16 '16 at 02:30

score 10 · Answer 18 · edited Jul 23 '23 at 00:51

10

For Ubuntu Server and Debian:

No need to create exports in bashrc or deal with dpkg-reconfigure.

Just replace the contents of /etc/default/locale with:

LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8

edited Jul 23 '23 at 00:51

Sridhar Sarnobat

25,183
12
93
106

answered Nov 05 '21 at 17:36

David Morales

17,816
12
77
105

1

Even though this had no effect, through some kind of trail I can't retrace I found the solution for me (https://askubuntu.com/a/227513/126830): `sudo locale-gen "en_US.UTF-8"`. So until further notice, thank you for posting this :) – Sridhar Sarnobat Aug 30 '22 at 05:01
Works for me as suggested by @SridharSarnobat – Mirko Pagliai Jul 20 '23 at 07:33

score 10 · Answer 19 · answered May 11 '22 at 19:41

Debian GNU/Linux 11 (bullseye)

I encountered this issue after creating a brand new VM instance in GCP.

Basically, I have just run the following

$ sudo apt-get update
$ sudo apt-get upgrade

Here I have got the error

perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "UTF-8",
LC_TERMINAL = "iTerm2",
LANG = "C"
are supported and installed on your system.

Here is how I fixed it.

Install the locales first.

$ sudo apt-get install locales

Open the locale file (use your favorite editor).

$ sudo nano /etc/default/locale

Add the following and save it.

LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8

Run the following.

$ sudo localedef -i en_US -f UTF-8 en_US.UTF-8

Restart your terminal.
Run the command to test and close it via ctrl + d.

$ perl

Note: I created an instance to just test my solution in order to ensure. Please let me know if it doesn't work for you.

I hope it helps you.

score 9 · Answer 20 · edited Dec 04 '20 at 18:35

9

For anyone connecting to DigitalOcean or some other Cloud hosting provider from the iTerm2.app on macOS v10.13 (High Sierra) and getting this error on some commands:

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 a fallback locale ("en_US.UTF-8").

This fixed the problem for me:

edited Dec 04 '20 at 18:35

Peter Mortensen

30,738
21
105
131

answered Oct 25 '17 at 17:52

Blago Eres

1,328
12
17

Yup was this setting in iterm2! Thanks! – Brian Olsen Dec 07 '18 at 13:40

score 9 · Answer 21 · edited Dec 04 '20 at 18:42

9

For me, I fixed this error by editing the .bashrc file, adding exports. Add after the initial comments.

Add language support.

export LANGUAGE=en_US.UTF-8
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
export LC_TYPE=en_US.UTF-8

edited Dec 04 '20 at 18:42

Peter Mortensen

30,738
21
105
131

answered Jan 03 '18 at 17:07

LandiLeite

555
7
7

Using LC_ALL shouldn't be necessary as it is meant for use during debugging. LC_ALL overrides all locale settings. – Can H. Tartanoglu Apr 29 '21 at 08:20

Nuvanda · Answer 22 · 2018-12-30T17:07:55.377

6

Adding the correct locale to ~/.bashrc, ~/.bash_profile, /etc/environment and the like will solve the problem, however it is not recommended, as it overrides the settings from /etc/default/locale, which is confusing at best and may lead to the locales not being applied consistently at worst.

Instead, one should edit /etc/default/locale directly, which may look something like this:

LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE=en_US

The change will take effect the next time you log in. You can get the new locale in an existing shell by sourcing /etc/default/locale like this:

$ . /etc/default/locale

edited Dec 30 '18 at 17:07

answered Mar 03 '18 at 21:14

Nuvanda

474
4
14

2

need to restart system after this step – Ghanshyam Bagul Dec 29 '18 at 13:57
You can simply comment in the desired locale in "/etc/locale.gen" then run: `locale-gen` – Dave Everitt Apr 12 '20 at 11:57
This is dubious advice. It's perfectly legitimate for the OS to have a default setting but for individual users to want to override that default. On multi-user servers, the OS might be set to use `en_US.utf-8`, but individual users from other continents might prefer or even require `pt_BR.utf-8`, `ja_JP.utf-8`, `fr_BF.utf-8`, etc. – tripleee May 01 '23 at 11:34

score 5 · Answer 23 · edited Dec 04 '20 at 18:37

5

Add missing locales to file .bash_profile:

echo "export LANGUAGE=en_US.UTF-8
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8">>~/.bash_profile

Then source your .bash_profile file:

source ~/.bash_profile

edited Dec 04 '20 at 18:37

Peter Mortensen

30,738
21
105
131

answered Nov 08 '17 at 09:44

Parinda Rajapaksha

2,963
1
36
40

lanoxx · Answer 24 · 2020-12-05T16:03:33.307

If this problem occurs while you are connecting via ssh to a remote host then it is possible that the remote system is missing certain locales. I am not going to repeat how to install and configure locales as this has been well explained by other answers already.

As other answers have pointed out, ssh should be passing your local computer's locales to the remote host. For example, if you have Australian locales set (e.g., en_AU.UFT-8), and you are connecting to a newly setup Ubuntu Server which only comes with en_US.UTF-8 then you will receive this warning.

To solve this problem you have several options:

Install the required locales on the remote host such that they match locales configured on your client.
Change the SSH configuration to not pass your clients' environment variables. I would not recommend this.
Override the locale on your remote machine by exporting locale settings from file .bashrc and friends.

score 4 · Answer 25 · edited Jan 08 '16 at 23:02

4

Following the accepted answer:

LANG=C ssh hunter2.

LC_ALL=C ssh hunter2

on the client side did the trick for me.

edited Jan 08 '16 at 23:02

Peter Mortensen

30,738
21
105
131

answered Feb 16 '14 at 17:56

Alex Kosenkov

145
2
5

Worked for me on OSX 10.10.3, while only "LANG=C" was not enough. Thanks Alex! – Christian May 17 '15 at 08:14

Adrian W · Answer 26 · 2019-05-03T18:45:18.747

4

Another Git-related answer:

The source of the problem might be the Git server. If all else fails, try doing dpkg-reconfigure locales (or whatever is appropriate for your distribution) on the server.

edited May 03 '19 at 18:45

answered Apr 29 '14 at 20:10

Adrian W

4,563
11
38
52

score 4 · Answer 27 · answered Dec 25 '16 at 11:02

4

With zsh ohmyzsh I added this to the .zshrc:

 # You may need to manually set your language environment
 LANGUAGE=en_US.UTF-8
 LANG=en_US.UTF-8
 LC_CTYPE=en_US.UTF-8
 LC_ALL=en_US.UTF-8

By removing the line export LANG=en_US.UTF-8

Reopened a new tab and SSHed in, worked for me :)

answered Dec 25 '16 at 11:02

Rip3rs

1,284
12
21

What is *"zsh ohmyzsh"*? – Peter Mortensen Dec 04 '20 at 18:28
ZSH is a different type of terminal, from the standard one. Oh. My ZSH is meant to improve that same terminal. from website: `Oh My Zsh is a delightful, open source, community-driven framework for managing your Zsh configuration. It comes bundled with thousands of helpful functions, helpers, plugins, themes, and a few things that make you shout...` https://ohmyz.sh/ – Rip3rs Dec 05 '20 at 12:48

score 4 · Answer 28 · edited Dec 04 '20 at 18:51

4

Source of the problem

I experienced this, logging in from one machine to another via ssh. The remote machine didn’t have the locale files, that I had on my local machine. You can either disable the forwarding of the locale from your local machine to the remote machine (in the file /etc/ssh/sshd_config remove the line AcceptEnv LANG LC_CTYPE …) or install the locale (changing it is not necessary in this case).

Installing

On Fedora, Red Hat Linux, and CentOS I used

sudo dnf install langpacks-de

for the German (de) language packs. I logged out, in, and it worked.

Search for other langpacks with

dnf search langpacks-

Changing/Activating

To list available locales I used

localectl list-locales

And to set a new one

sudo localectl set-locale de_DE.utf8

edited Dec 04 '20 at 18:51

Peter Mortensen

30,738
21
105
131

answered Feb 06 '20 at 23:39

erik

2,278
1
23
30

I'm on Mac and don't see `AcceptEnv LANG LC_CTYPE` in `/etc/ssh/sshd_config`. Any suggestions? Thx – Houman Aug 26 '22 at 08:26
I found it under `/etc/ssh/sshd_config.d/100-macos.conf` but commenting it out and restarting, still didn't help. – Houman Aug 26 '22 at 08:41

score 4 · Answer 29 · answered Sep 03 '20 at 06:16

Export the variable

$ export LANGUAGE=en_US.UTF-8
$ export LC_ALL=en_US.UTF-8
$ export LANG=en_US.UTF-8
$ export LC_CTYPE=en_US.UTF-8

Next run

$ sudo locale-gen
$ sudo dpkg-reconfigure locales

When you run dpkg-reconfigure locales it asks you to choose the locales, choose en_US.UTF-8 . If you run this by selecting all locales, it will take some time to configure.

score 3 · Answer 30 · edited Jan 08 '16 at 23:10

3

In my case, this was the output:

LANGUAGE = (unset),
LC_ALL = (unset),
LC_PAPER = "ro_RO.UTF-8",
LC_ADDRESS = "ro_RO.UTF-8",
....

The solution was:

sudo locale-gen ro_RO.UTF-8

edited Jan 08 '16 at 23:10

Peter Mortensen

30,738
21
105
131

answered Nov 08 '14 at 19:03

Rodislav Moldovan

1,175
1
13
20

I also see `LANGUAGE = (unset)` but don't have the `locale-gen` command – PatS Aug 10 '22 at 14:05

score 3 · Answer 31 · edited Jan 08 '16 at 23:13

3

Add LC_ALL="en_GB.utf8" to /etc/environment and reboot. That's all.

edited Jan 08 '16 at 23:13

Peter Mortensen

30,738
21
105
131

answered Jul 13 '15 at 08:24

zires

554
6
16

score 3 · Answer 32 · answered Oct 04 '16 at 14:36

3

If you don't care about the locale issue, you can set PERL_BADLANG=0. Of course, this could result in incorrect localisation.

answered Oct 04 '16 at 14:36

Craig Ringer

307,061
76
688
778

score 3 · Answer 33 · edited Dec 04 '20 at 18:32

3

In my case, with Debian 8.6 (Jessie), I had to change settings in:

/etc/ssh/ssh_config` for `#AcceptEnv LANG LC_*

and

sshd_config for #SendEnv LANG LC_*

Then restart the ssh service.

At last, I did:

locale-gen en_US.UTF-8 and dpkg-reconfigure locales

edited Dec 04 '20 at 18:32

Peter Mortensen

30,738
21
105
131

answered Aug 06 '17 at 08:44

java newbees

31
2

score 3 · Answer 34 · edited Dec 04 '20 at 18:41

In Arch Linux using a UK keyboard and locale, I had the following error:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.utf8"

Exporting my locales in /etc/profile didn't fix it.
I did however fix this by editing /etc/locale.gen, also enabling the en_US.utf8 locale that perl expected to find, and running local-gen.

(I use pac-manager which uses a whole bunch of perl modules from AUR, so reinstalling perl in my particular case would be a nuisance.)

score 3 · Answer 35 · edited Dec 04 '20 at 18:55

I have this issue whenever I run a Perl script, such as enum4linux, on the latest Kali Linux version.

kali@kali:~$ lsb_release -a
No LSB modules are available.
Distributor ID:    Kali
Description:    Kali GNU/Linux Rolling
Release:    2020.3
Codename:    kali-rolling
kali@kali:~$

E.g.,

kali@kali:~$ enum4linux
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
    LANGUAGE = (unset),
    LC_ALL = (unset),
    LC_ADDRESS = "ms_MY.UTF-8",
    LC_NAME = "ms_MY.UTF-8",
    LC_MONETARY = "ms_MY.UTF-8",
    LC_PAPER = "ms_MY.UTF-8",
    LC_IDENTIFICATION = "ms_MY.UTF-8",
    LC_TELEPHONE = "ms_MY.UTF-8",
    LC_MEASUREMENT = "ms_MY.UTF-8",
    LC_TIME = "ms_MY.UTF-8",
    LC_NUMERIC = "ms_MY.UTF-8",
    LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
enum4linux v0.8.9 (http://labs.portcullis.co.uk/application/enum4linux/)
Copyright (C) 2011 Mark Lowe (mrl@portcullis-security.com)

Look at the warning message given.

perl: warning: Falling back to a fallback locale ("en_US.UTF-8").

Also, notice that LC_ALL = (unset)

The solution is simple. All you have to do is to set it.

export LC_ALL=en_US.UTF-8

E.g.,

kali@kali:~$ export LC_ALL=en_US.UTF-8
kali@kali:~$

And problem solved

kali@kali:~$ enum4linux
enum4linux v0.8.9 (http://labs.portcullis.co.uk/application/enum4linux/)
Copyright (C) 2011 Mark Lowe (mrl@portcullis-security.com)

For a permanent solution, you might want to add it to the .bashrc file.

score 2 · Answer 36 · edited Jan 08 '16 at 23:08

As always, the devil is in the detail...

On Mac OS X v10.7.5 (Lion), to fix some Django error, in my ~/.bash_profile I've set:

export LANG=en_EN.UTF-8
export LC_COLLATE=$LANG
export LC_CTYPE=$LANG
export LC_MESSAGES=$LANG
export LC_MONETARY=$LANG
export LC_NUMERIC=$LANG
export LC_TIME=$LANG
export LC_ALL=$LANG

And in turn for a long time I got that warning when using Perl.

My bad! As I've realized much later, my system is en_US.UTF-8! I fixed it simply by changing from

export LANG=en_EN.UTF-8

to

export LANG=en_US.UTF-8

score 2 · Answer 37 · edited May 10 '17 at 22:30

2

All the previous answers are wrong. The message is clear - missing locale. The solution is to add the appropriate locale. You do that by editing the /etc/locale.gen file, remove the # sign in front of the locale being reported as missing and then issuing the command:

$ sudo locale-gen

This will actually generate the locales specified in /etc/locale.gen and therefore the message will not be shown.

edited May 10 '17 at 22:30

Peter Mortensen

30,738
21
105
131

answered May 10 '17 at 21:27

Matthias Hryniszak

3,099
3
36
51

This is simply *the* answer and worked on ancient Debian (6) for me. All the rest are over-complicated and a bit off-track. – Dave Everitt Apr 12 '20 at 11:53

score 2 · Answer 38 · edited Dec 04 '20 at 18:57

2

perl -e exit
sudo localedef -i en_US -f UTF-8 en_DE.UTF-8
#                                   DE = German
# Use your country code en lieu of  DE

# The second "perl" should then not complain any more
perl -e exit

localectl list-locales # Just make sure it is OK

edited Dec 04 '20 at 18:57

Peter Mortensen

30,738
21
105
131

answered Oct 10 '20 at 22:14

dotbit

4,445
1
7
8

be aware that after this you might run into: "kwin_xkbcommon: XKB: couldn't find a Compose file for locale "en_DE.UTF-8" on KDE , tbh. Yet perl is quite happy with it. – dotbit Oct 11 '20 at 06:43
Thank you for this post. What is strange (to me) is that simply setting the environment variables in my .bashrc (before running any perl commands involved in my login) **did not work**. This solution did, so thanks a bunch – PatS Aug 10 '22 at 14:11

score 2 · Answer 39 · answered May 02 '22 at 10:27

I had multiple users using different shells so in my case this solved:

Check which shell
echo $0
if bash
echo "# Setting locale\nLC_CTYPE=en_US.UTF-8\nLC_ALL=en_US.UTF-8" >> .bashrc
if zsh
echo "# Setting locale\nLC_CTYPE=en_US.UTF-8\nLC_ALL=en_US.UTF-8" >> .zshrc

score 2 · Answer 40 · answered Feb 16 '23 at 11:14

2

If you are using iTerm2 on MacOS this issue can be solved by unchecking this setting: iTerm2 > Settings > Profiles > Terminal > Set locale variables automatically:

answered Feb 16 '23 at 11:14

Gerard de Visser

7,590
9
50
58

score 1 · Answer 41 · edited Jan 08 '16 at 23:14

1

ssh overwrites LC locale variables by default. See /etc/ssh/sshd_config:

AcceptEnv LANG LC_*

So maybe you need to set these variables in your local shell.

edited Jan 08 '16 at 23:14

Peter Mortensen

30,738
21
105
131

answered Aug 27 '15 at 14:02

garaboncias

181
1
3

score 1 · Answer 42 · edited May 10 '17 at 22:29

1

For me, on Ubuntu 16.04 (Xenial Xerus) the following worked:

root@host:~#locale-gen en_GB.UTF-8
root@host:~#localectl set-locale LANG=en_GB.UTF-8,LC_ALL=en_GB.UTF-8

Then reboot...

edited May 10 '17 at 22:29

Peter Mortensen

30,738
21
105
131

answered Oct 21 '16 at 20:18

Aleksandar Pavić

3,143
1
34
36

score 1 · Answer 43 · answered Nov 24 '21 at 00:10

1

I had LC_COLLATE=C set on my machine on /etc/locale.conf. I simply deleted that line, so that only LANG=en_US.UTF-8 (or equivalent for you) is set, and get no more problems.

answered Nov 24 '21 at 00:10

Real

192
1
8

EpicVoyage · Answer 44 · 2019-01-12T17:35:58.400

0

If you are running a chroot in CentOS, try manually copying /usr/lib/locale to the chroot environment for the account that is having this issue.

edited Jan 12 '19 at 17:35

answered Apr 19 '14 at 18:21

EpicVoyage

604
7
20

2

Where to should these be copied? – kontur Jan 11 '19 at 11:08
Copy it into the chroot environment of the account that you are having trouble with. In my case (with Plesk) this was to `/var/www/vhosts/[domain]/usr/lib/`, but you will have to determine this path for your server/account. – EpicVoyage Jan 12 '19 at 17:34

score 0 · Answer 45 · edited Dec 04 '20 at 18:49

0

Setting the LC_TYPE environment variable to the default locale language "C" will help to suppress this warning.

Run export LC_CTYPE="C" and try to run the perl command.

P.S: You need to set this variable in one of file /etc/environment or file /etc/default/locale for a permanent solution.

edited Dec 04 '20 at 18:49

Peter Mortensen

30,738
21
105
131

answered Dec 18 '19 at 05:46

Bharath Kumar

935
7
13

for csh shell, run the command : setenv LC_CTYPE "C". We can also add the same in ~/.cshrc file and then run the command "source ~/.cshrc" to re-load the variables. – gaurav kumar Mar 19 '21 at 10:04

score 0 · Answer 46 · answered Sep 18 '21 at 11:29

In case someone has a server with Strato and tries to figure this out, check /etc/profile. I was regenerating locales and setting variables for too long before I found out that there are two lines at the end of this file which overwrote my locale settings all the time.

score 0 · Answer 47 · answered Apr 06 '22 at 03:13

0

Tried those ways on Mac M1 Monterey, but no one works. My quick way to disable that message: Open Terminal -> Preferences -> Advanced tab -> uncheck to Set locale environment variables on startup

answered Apr 06 '22 at 03:13

Khoi Ngo

941
8
16

score -4 · Answer 48 · edited Jan 08 '16 at 23:15

-4

Try to reinstall:

localess apt-get install --reinstall locales

Read more in How to change the default locale

edited Jan 08 '16 at 23:15

Peter Mortensen

30,738
21
105
131

answered Oct 21 '15 at 06:09

VladVons

27
3

How to fix a locale setting warning from Perl

48 Answers48

For macOS & Mac OS X users only

Add language support.

Source of the problem

Installing

Changing/Activating

Linked

Related