SVN cannot set LC_CTYPE locale
SvnLocaleSvn 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.
- We must instal support for the correct locale (localadm for sunos, locale-gen for linux)
- 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.