65

I started getting the following error whenever i use SVN in my server:

svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LC_CTYPE is UTF-8
svn: warning: please check that your locale name is correct

my guess is that there might be something wrong with my svn client(Using Versions App) and the server svn...

how can i make this warning disappear forever from the server whenever i use such commands?

stergosz
  • 5,754
  • 13
  • 62
  • 133

13 Answers13

68

Check the output of

locale -a

If the locale that SVN is complaining about isn't installed, then you can install it.

You might need to do for Debian or similar systems:

sudo dpkg-reconfigure locales

If you want to configure locales manually:

sudo vim /etc/locale.gen # and add "en_US.UTF-8 UTF-8"
sudo locale-gen

Or if your locale-gen supports an argument (NOT for Debian):

sudo locale-gen en_GB.UTF-8
sudo locale-gen en_US.UTF-8

Alternatively as Ankit writes in his answer:

export LC_ALL=C

may work (in your current session, or in your .profile).

shawn
  • 4,305
  • 1
  • 17
  • 25
JeeBee
  • 17,476
  • 5
  • 50
  • 60
  • For those on solaris (sorry): You'll want to configure the locale adm and then add in the correct locale (e.g., localeadm -l -v ; localeadm -a en_US.UTF-8 -d /cdrom/sol_10_811_x86) http://www.netlinxinc.com/index.php?option=com_content&view=article&id=50:.. – Peter Kahn Dec 27 '12 at 22:02
  • 5
    on debian(and maybe also Ubuntu) systems, locale-gen does not take arguments, but generates what is activated in /etc/locale.gen. Plus, on an Deian-based Univention Corporate Server, this file is generated by the config registry, so the values for desired / needed / missing locales must be set like this: ucr set locale='de_DE.UTF-8:UTF-8 en_US.UTF-8:UTF-8' – Henning Feb 18 '15 at 13:52
  • For me, adding "env LC_ALL=C" to /usr/share/applications/jetbrains-idea.desktop fixed it. – Smile4ever Oct 24 '15 at 14:22
  • 2
    I got the same warning from subversion, and setting export LC_ALL=en_GB.UTF-8 worked (after running sudo locale-gen en_GB.UTF-8). I think it's better than setting it to the C locale. – Sorin Postelnicu Feb 16 '16 at 17:04
  • Getting this on macOS Sierra, when talking to some old(?) server `svn checkout svn+ssh://......` Is it really my system that has the problems, or is it the old(?) server? – Jonny Dec 21 '16 at 01:32
  • 1
    I just tried to fix this question. Using `sudo dpkg-reconfiguration locales` to replace `sudo apt-get install language-pack-en-base` is better in my **Debian** system. – piglovesx Jul 26 '17 at 01:07
  • @JeeBee should write the alternate answer at the top. – backslashN Aug 12 '20 at 07:51
49

Although setting LC_CTYPE to an empty value worked for me, the underlying reason was that the app Terminal on my Mac was setting the locales on startup, even when I SSH to another system.

This can be fixed in Terminal > Preferences:

  • Select "Profiles" tab and select “Advanced” from sub-tabs
  • Uncheck "Set locale environment variables on startup"
Mike
  • 3,722
  • 1
  • 28
  • 41
Andreas K
  • 580
  • 4
  • 7
  • Yes this fixed it for me using Mavericks – Maarten Hartman Jan 06 '14 at 12:38
  • 1
    There is couple of other alternatives how to solve this on Mac OSX: http://www.cyberciti.biz/faq/os-x-terminal-bash-warning-setlocale-lc_ctype-cannot-change-locale/ – Ales Teska Dec 27 '14 at 10:28
  • exactly what i encountered,but if i uncheck it, the terminal can not display chinese file name. – acerphenix Nov 23 '15 at 07:18
  • I also noticed a problem with non-ASCII characters recently. In my case the Swedish characters åäö stopped working, perhaps related to updating to Yosemite. – Andreas K Nov 23 '15 at 10:18
28

If you want to fix this, set the “LC_ALL” variable manually.

To make it permanent just edit the file “/etc/environment” and add the line:

LC_ALL=C

Save the file and exit the editor. In order for it to apply you have to logout of the current shell session. The next time you log in, the issue with SVN will be gone.

Ankit
  • 900
  • 7
  • 9
15

LC_ALL and LANG settings did not work for me but LC_CTYPE did.

LC_CTYPE=en_US.UTF-8
Caner
  • 329
  • 3
  • 4
  • This appears to be the correct solution to me (on macOS at least). The other solutions resulted in Terminal not properly displaying UTF-8 file names, but after setting LC_CTYPE correctly, file names are displayed properly and the svn warnings are gone. – Joe Strout Jun 21 '18 at 14:50
9

On Debian Jessie:

I ran:

sudo dpkg-reconfigure locales

Added and installed the missing locale. Then it worked.

LaGrandMere
  • 10,265
  • 1
  • 33
  • 41
3

commenting out the lines with SendEnv LANG LC_* in /etc/ssh/ssh_config helps to me (openSUSE)

Subdigger
  • 2,166
  • 3
  • 20
  • 42
  • It can also be configured on the remote server by removing `AcceptEnv LANG LC_*` in /etc/ssh/sshd_config. I recommend doing both. I think this is a better solution than changing the Terminal configuration or installing unnecessary locales on the server. – Christian Schmidt Oct 25 '17 at 20:14
2

This is caused by not having the proper locales generated on your system.

Uncommented lines that you want to support in /etc/locale.gen

For example:

en_GB.UTF-8 UTF-8
en_US.UTF-8 UTF-8
ru_RU.UTF-8 UTF-8

and then run sudo locale-gen

Vadim Bryl
  • 151
  • 3
1

We had this problem in our company as well, when using IntelliJ. A colleague of mine just fixed it.

For us the problem was the line SendEnv LANG LC_* in /etc/ssh/ssh_config. When I commented out that line, everything worked fine.

Moritz Schmitz v. Hülst
  • 3,229
  • 4
  • 36
  • 63
1

For iTerm2:

Profiles → Open Profiles… → Edit Profiles… → Terminal → Unckeck Set locale variables automatically

Dmitriy Dokshin
  • 710
  • 5
  • 25
0

I found that combining several answers hear yields correct behavior.

  1. We must instal support for the correct locale (localadm for sunos, locale-gen for linux)
  2. We must set LC_ALL to the appropriate locale

This depends on what kinds of file names you have in your source tree. For example, I have english, hebrew and arabic. en_US.UTF-8 works for me "C" on it's own led to files which I couldn't update.

Peter Kahn
  • 12,364
  • 20
  • 77
  • 135
0

I got the issue when I connect to a remote ssh server (ssh is used by svnserve -> svn update command).

The reason is that the remote server does not have the language pack available which is set in $LANG on the local server.

You can check the installed language packs by 'locale -a'. The $LANG language must be configured on the remote server.

E.g.

Local server: LANG=en_US.UTF-8

Remote server: locale -a -> only de_DE.UTF-8 is available

Resolution: Just install missing language pack on remote server: dpkg-reconfigure locales;

btw: the selected default language does not matter.

Markus
  • 1
0

Adding just one more option that worked for me on a RHEL6 system.

/etc/sysconfig/i18n contained LANG="en_US.UTF-8" but locale -a | grep -i en_us showed en_US.utf8.

After updating /etc/sysconfig/i18n to match the output of locale -a the problem was resolved.

Bram
  • 819
  • 1
  • 9
  • 24
0

For anyone else stuck with SVN, here's the fix for RHEL/CentOS/Rocky Linux 8.x:

On the SVN server, make sure the glibc-langpack-en package is installed.

If your clients come to the table with more exotic locales, I guess the relevant package for those languages will be needed as well.

bolind
  • 512
  • 3
  • 15