CentOS 6 et erreur locale


16

Je viens d'installer CentOS 6 et chaque fois que je me connecte au système via SSH à distance, j'obtiens l'erreur suivante:

-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8)

Lorsque je tape "locale" sur la ligne de commande, j'obtiens la sortie suivante:

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE=UTF-8
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Quel peut être le problème? Comment puis-je résoudre ce problème?


votre solution de commenter l'argument SendEnv LANG LC_ * a fonctionné pour moi sur Mac OS X 10.7.5

Réponses:


10

Sur le serveur d'où vous venez, avez-vous des paramètres régionaux définis via une variable d'environnement? En regardant mon installation CentOS 6, le seul environnement local que je peux trouver pris en charge est identifié comme en_US.utf8(découvert à l'aide de la locale -acommande). Est-ce que ceci pourrait être le problème?

Lors de mes tests, lorsque j'ai défini la LC_ALLvariable d'environnement sur en_US.UTF-8, ssh'd sur le serveur, la sortie de ma commande locale a été définie POSIXdans mon cas. C'est la même chose que lorsque je n'ai PAS défini (c'est-à-dire non défini) la LC_ALLvariable avant ssh'ing.

Lorsque j'ai défini ma LC_ALLvariable sur en_US.utf8ou en_US.utf-8, ssh sur ma boîte CentOS 6, la sortie des paramètres régionaux était la même que celle définie sur la boîte source.

Remarquez que je n'ai pas utilisé de capuchons pour UTF également.


11
Soit dit en passant, j'ai remarqué que cela se produisait à partir de mes paramètres ssh de Mac OS X Lion. J'ai édité le fichier / etc / ssh_config et commenté SendEnv LANG LC_ *. Cela a résolu mon problème.
Cem

@Cem Merci pour le conseil, cela le corrige en effet sur Mac OS X Lion.
Zsolt Török

17

Résolu cela en désactivant «Définir les variables d'environnement locales au démarrage» dans Paramètres du terminal> Avancé selon cette capture d'écran.

entrez la description de l'image ici

REMARQUE: si vous utilisez iTerm2, vous pouvez désactiver l'option "Définir automatiquement les variables locales" dans Préférences> Profils> Terminal


1
Cela a fonctionné pour moi. Plus précisément, Terminal.app définissait "LC_CTYPE = UTF-8", ce qui provoquait ensuite les erreurs signalées par l'OP. Sinon, unset LC_CTYPEou export LC_CTYPE=en_US.UTF-8fixup le problème après la connexion.
tard

Cela m'a résolu, thx
pjvds

11

Manière simple:

Ajouter

 LC_CTYPE="en_US.UTF-8"

à /etc/sysconfig/i18n.


Cela fonctionne pour moi, après tant d'essais.
Tommy

2

Ce qui a fonctionné pour moi a été d'ajouter un lien symbolique dans le serveur CentOS comme ceci:

ln -s /usr/lib/locale/en_US.utf8 /usr/lib/locale/UTF-8

Une fois que vous avez fait ces commandes comme ceci,

export LC_CTYPE=UTF-8

Si vous ne le faites pas, cette dernière commande échoue avec cette erreur:

-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory

Maintenant, une solution encore plus simple consiste simplement à ajouter cette ligne à / etc / bashrc dans le serveur:

export LC_CTYPE="en_US.utf8"

Merci pour la contribution! cela a vraiment bien fonctionné. Enfin capable de supprimer ce commentaire ennuyeux ...
cristobal

2

J'ai ce message spécifique lorsque je me connecte d'un Solaris X à un hôte Centos.

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Le problème vient de 2 paramètres:

  1. Dans mon système par défaut ssh_config, je demande au système de transmettre ces variables.

Envoyer des variables d'environnement liées aux paramètres régionaux SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES

  1. Sur mon hôte source, ces paramètres ont été définis de cette façon:

    SOURCE # LANG = LC_CTYPE = fr_FR.UTF-8 LC_NUMERIC = fr_FR.UTF-8 LC_TIME = fr_FR.UTF-8 LC_COLLATE = fr_FR.UTF-8 LC_MONETARY = fr_FR.UTF-8 LC_MESSAGES = fr.UTF-8 LC_ALL =

Mais, comme vous pouvez le voir, le LC_MESSAGES est défini sur fr.UTF-8, qui n'est pas une option sur mon hôte de destination.

 DEST#locale -a | grep fr_FR
 fr_FR
 fr_FR@euro
 fr_FR.iso88591
 fr_FR.iso885915@euro
 fr_FR.utf8

Le problème a été résolu en forçant sur mon hôte source, sur .bash_profile: # export LC_ALL = fr_FR.UTF-8 export LANG = fr_FR.UTF-8

J'aurais pu le résoudre en demandant à mon hôte dest de ne pas prendre cette variable à partir d'une connexion ssh (généralement, ou en créant un fichier ssh_config local pour mon utilisateur)


1

Sur un système Centos 6.2 local: cela n'a pas aidé:

localedef -i en_US -f UTF-8 en_US.UTF-8

Cela a fonctionné:

localedef --no-archive -i en_US -f UTF-8 en_US.UTF-8

J'ai également supprimé locale-archivedans /usr/lib/locale. Je ne sais pas si c'était nécessaire.


1

C'était mon correctif dans le passé pour les erreurs locales.

Exécutez ce qui suit: locale-gen

Modifiez ensuite /etc/locale.gen. Assurez-vous que les éléments suivants ne sont pas commentés:

en_US.UTF-8 UTF-8  
en_US ISO-8859-1  

generate locale

locale-gen

1

Avec Iterm2 , c'est différent.
Allez à Iterm2 -> Preferences, puis allez à l' Profilesonglet et choisissez l' Terminalonglet en bas.
Accédez à la Environmentcatégorie et décochez;

Définir automatiquement les variables locales

Enfin, fermez et démarrez une nouvelle session.

entrez la description de l'image ici


0

et assurez-vous LC_ALL="en_US.UTF-8" est dans ou ajouté au / etc / sysconifg / i18n

exemple de contenu

LANG="en_GB.UTF-8"
SYSFONT="latarcyrheb-sun16"
LC_ALL="en_US.UTF-8" 

-3

Éditer /etc/sysconfig/i18n

Remplacer LANG="us"parLANG="en_US"

Enregistrez et quittez, déconnectez-vous et reconnectez-vous.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.