SVN cannot set LC_CTYPE locale

Question

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?

Answer 1

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

Answer 2

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"

Answer 3

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.

Answer 4

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

LC_CTYPE=en_US.UTF-8

Answer 5

On Debian Jessie:

I ran:

sudo dpkg-reconfigure locales

Added and installed the missing locale. Then it worked.

Answer 6

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

Answer 7

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

Answer 8

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.

Answer 9

For iTerm2:

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

Answer 10

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.

Answer 11

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.

Answer 12

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.