SVN ne peut pas définir les parameters régionaux LC_CTYPE

J’ai commencé à recevoir l’erreur suivante chaque fois que j’utilise SVN sur mon serveur:

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 

J’imagine qu’il y a peut-être quelque chose qui ne va pas avec mon client svn (Utilisation de l’application Versions) et le serveur svn …

Comment puis-je faire disparaître cet avertissement du serveur à chaque fois que j’utilise ces commandes?

Vérifiez la sortie de

 locale -a 

Si les parameters régionaux dont se plaint SVN ne sont pas installés, vous pouvez les installer.

Vous devrez peut-être faire:

 sudo apt-get install language-pack-en-base 

suivi de l’un des (selon l’erreur exacte de SVN, le vôtre est le premier cas):

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

Comme Ankit écrit dans sa réponse :

 export LC_ALL=C 

peut fonctionner (dans votre session en cours, ou dans votre fichier .profile).

Bien que le réglage de LC_CTYPE sur une valeur vide ait fonctionné pour moi, la raison sous-jacente était que l’application Terminal sur mon Mac définissait les locales au démarrage, même lorsque je SSH sur un autre système.

Cela peut être corrigé dans Terminal> Préférences:

  • Sélectionnez l’onglet “Profils” et sélectionnez “Avancé” dans les sous-tabs
  • Décochez la case “Définir les variables d’environnement locales au démarrage”

Si vous souhaitez résoudre ce problème, définissez manuellement la variable «LC_ALL».

Pour le rendre permanent, éditez simplement le fichier “/ etc / environment” et ajoutez la ligne:

 LC_ALL=C 

Enregistrez le fichier et quittez l’éditeur. Pour qu’il s’applique, vous devez vous déconnecter de la session shell en cours. La prochaine fois que vous vous connecterez, le problème avec SVN aura disparu.

Les parameters LC_ALL et LANG n’ont pas fonctionné pour moi, mais LC_CTYPE l’a fait.

 LC_CTYPE=en_US.UTF-8 

Sur Debian Jessie :

Iran:

 sudo dpkg-reconfigure locales 

Ajout et installation de la locale manquante Puis ça a fonctionné.

commenter les lignes avec SendEnv LANG LC_* dans / etc / ssh / ssh_config m’aide (openSUSE)

Cela est dû au fait que les locales appropriées ne sont pas générées sur votre système.

Lignes non commentées que vous souhaitez prendre en charge dans /etc/locale.gen

Par exemple:

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

puis lancez sudo locale-gen

Nous avons également eu ce problème dans notre société lors de l’utilisation d’IntelliJ. Un de mes collègues vient de le réparer.

Pour nous, le problème était la ligne SendEnv LANG LC_* dans /etc/ssh/ssh_config . Lorsque j’ai commenté cette ligne, tout a bien fonctionné.

Pour iTerm2:

Profils → Ouvrir les profils… → Modifier les profils… → Terminal → Unckeck Définir automatiquement les variables locales

J’ai trouvé que la combinaison de plusieurs réponses permet d’entendre le comportement correct.

  1. Nous devons installer le support pour la locale correcte (localadm pour sunos, locale-gen pour linux)
  2. Nous devons définir LC_ALL sur les parameters régionaux appropriés

Cela dépend des types de noms de fichiers que vous avez dans votre arbre source. Par exemple, j’ai l’anglais, l’hébreu et l’arabe. en_US.UTF-8 fonctionne pour moi “C” seul a conduit à des fichiers que je ne pouvais pas mettre à jour.

J’ai eu le problème quand je me connecte à un serveur ssh distant (ssh est utilisé par svnserve -> commande svn update).

La raison en est que le serveur distant ne dispose pas du module linguistique défini dans $ LANG sur le serveur local.

Vous pouvez vérifier les modules linguistiques installés par «locale -a». Le langage $ LANG doit être configuré sur le serveur distant.

Par exemple

Serveur local: LANG = en_US.UTF-8

Serveur distant: locale -a -> seul de_DE.UTF-8 est disponible

Solution: installez simplement le module linguistique manquant sur le serveur distant: dpkg-reconfigure locales;

btw: la langue par défaut sélectionnée n’a pas d’importance.