SVN cannot set LC_CTYPE locale

SvnLocale

Svn Problem Overview


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?

Svn Solutions


Solution 1 - Svn

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

Solution 2 - Svn

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"

Solution 3 - Svn

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.

Solution 4 - Svn

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

LC_CTYPE=en_US.UTF-8

Solution 5 - Svn

On Debian Jessie:

I ran:

sudo dpkg-reconfigure locales

Added and installed the missing locale. Then it worked.

Solution 6 - Svn

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

Solution 7 - Svn

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

Solution 8 - Svn

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.

Solution 9 - Svn

For iTerm2:

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

Solution 10 - Svn

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.

Solution 11 - Svn

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.

Solution 12 - Svn

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.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionstergoszView Question on Stackoverflow
Solution 1 - SvnJeeBeeView Answer on Stackoverflow
Solution 2 - SvnAndreas KView Answer on Stackoverflow
Solution 3 - SvnAnkitView Answer on Stackoverflow
Solution 4 - SvnCanerView Answer on Stackoverflow
Solution 5 - SvnLaGrandMereView Answer on Stackoverflow
Solution 6 - SvnSubdiggerView Answer on Stackoverflow
Solution 7 - SvnVadim BrylView Answer on Stackoverflow
Solution 8 - SvnMoritz Schmitz v. HülstView Answer on Stackoverflow
Solution 9 - SvnDmitriy DokshinView Answer on Stackoverflow
Solution 10 - SvnPeter KahnView Answer on Stackoverflow
Solution 11 - SvnMarkusView Answer on Stackoverflow
Solution 12 - SvnBramView Answer on Stackoverflow