Reputation: 13839
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?
Upvotes: 875
Views: 882158
Reputation: 10145
When connecting to a remote machine and using MacOS
Because the warning is only1 emitted by remote Linux systems you connect to, the least intrusive workaround is to not mess with the LC_*
variables on your local macOS.
Instead, just tell your SSH client to explicitly set its (forwarded-) environment variables.
In $HOME/.ssh/config
, add an override for all hosts:
Host *
SetEnv LANGUAGE=en_US.UTF-8 LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8
1: well, "most likely-" as of 2023.
Upvotes: 1
Reputation: 732
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 configures locales again.
Upvotes: 26
Reputation: 1036
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
The warning occurs when Perl can't determine the correct locale settings, usually because the locale isn't installed or the environment variables aren't set.
locale -a | grep en_US
For Ubuntu/Debian:
sudo locale-gen en_US.UTF-8
sudo update-locale
For CentOS/RHEL:
sudo dnf install glibc-langpack-en
For Arch Linux:
# Edit /etc/locale.gen and uncomment en_US.UTF-8
sudo nano /etc/locale.gen
sudo locale-gen
# For bash users (choose one):
echo 'export LC_ALL="en_US.UTF-8"
export LANG="en_US.UTF-8"
export LANGUAGE="en_US.UTF-8"' >> ~/.bashrc
# For zsh users:
echo 'export LC_ALL="en_US.UTF-8"
export LANG="en_US.UTF-8"
export LANGUAGE="en_US.UTF-8"' >> ~/.zshrc
LANG
: Sets the default localeLC_ALL
: Overrides all other locale settingsLANGUAGE
: Used for message language selectionsource ~/.bashrc # or source ~/.zshrc for zsh users
locale
Upvotes: 25
Reputation: 18064
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
Upvotes: 18
Reputation: 417
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
Upvotes: 20
Reputation: 8040
If you are using iTerm2 on MacOS this issue can be solved by unchecking this setting: iTerm2 > Settings > Profiles > Terminal > Set locale variables automatically:
Upvotes: 2
Reputation: 1052
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.
locales
first.$ sudo apt-get install locales
$ sudo nano /etc/default/locale
LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
$ 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.
Upvotes: 17
Reputation: 997
I had multiple users using different shells so in my case this solved:
echo $0
echo "# Setting locale\nLC_CTYPE=en_US.UTF-8\nLC_ALL=en_US.UTF-8" >> .bashrc
echo "# Setting locale\nLC_CTYPE=en_US.UTF-8\nLC_ALL=en_US.UTF-8" >> .zshrc
Upvotes: 2
Reputation: 1441
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
Upvotes: 1
Reputation: 191
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.
Upvotes: 1
Reputation: 83
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.
Upvotes: 0
Reputation: 13041
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.
Upvotes: 7
Reputation: 5015
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
Upvotes: 3
Reputation:
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 ([email protected])
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 ([email protected])
For a permanent solution, you might want to add it to the .bashrc
file.
Upvotes: 5
Reputation: 2446
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).
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-
To list available locales I used
localectl list-locales
And to set a new one
sudo localectl set-locale de_DE.utf8
Upvotes: 7
Reputation: 964
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.
Upvotes: 1
Reputation: 462
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.
Upvotes: 15
Reputation: 613
For me, I fixed this error by editing the .bashrc file, adding exports. Add after the initial comments.
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
Upvotes: 10
Reputation: 2447
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.)
Upvotes: 3
Reputation: 3109
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
Upvotes: 6
Reputation: 1348
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:
Upvotes: 9
Reputation: 31
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
Upvotes: 3
Reputation: 2765
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
Upvotes: 11
Reputation: 15162
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
Upvotes: 624
Reputation: 139411
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
LANG
environment variable in your shell's initialization file.ssh hunter2
, use the command LANG=C ssh hunter2
.SendEnv LANG LC_*
line in the local /etc/ssh/ssh_config
file. (Thanks to this answer. See Bug 1285 for OpenSSH for more.)Upvotes: 563
Reputation: 757
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.
Upvotes: 4
Reputation: 4849
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
Upvotes: 40
Reputation: 2069
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.
Upvotes: 193
Reputation: 5026
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.
Upvotes: 4
Reputation: 754
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.
Upvotes: 0