Impossible de définir LC_CTYPE sur les paramètres régionaux par défaut: aucun fichier ou répertoire de ce type


56

J'ai la question exacte, mais il n'y a pas de solution. J'ai essayé mais ça ne marche pas

Comment résoudre mon problème de paramètres régionaux?

$ locale
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
LANGUAGE=
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=

$ locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory
C
C.UTF-8
en_US.utf8
POSIX

Est-ce à cause de la non-concordance entre en_US.UTF-8 et en_US.utf8?

Comment réparer?


Avez-vous lu cette askubuntu.com/a/229512/387382 ?
Hélio

Réponses:


53

Ouvrez le terminal et lancez la commande ci-dessous:

export LC_ALL="en_US.UTF-8"

Cela fonctionne, mais pourquoi?
Yu Jiaao

16
Cela ne résout rien car la variable est détruite à la fin de la session.
Etienne Gautier


Excellente solution en si peu de mots. Lol!
Redbob

1
Lorsque j'exporte cette var, je reçois:-bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
nnyby le

36

Ce même problème (LC_CTYPE = UTF-8, ce qui est faux) peut se produire lorsque vous vous connectez via ssh depuis un Mac vers une boîte Linux, et que votre terminal définit automatiquement les variables d'environnement. Il y a une case à cocher pour cela. Décochez-la, et vous êtes prêt à partir. Dans iTerm c'est dans le profil-> Onglet Terminal.


2
dans iTerm, décochez la case "Préférences> Profils> Par défaut> Terminal> Environnement> Définir automatiquement les variables de paramètres régionaux"
ecerulm

1
-1: Bien que cela puisse fonctionner, c'est extrêmement invasif. Vous pouvez également potentiellement affecter le comportement de votre terminal local ainsi que celui de chaque hôte auquel vous vous connectez. Bien que vos conclusions soient vraies, il est préférable d’utiliser ssh_config pour qu’il n’envoie pas LC_ * aux hôtes connus pour avoir des problèmes.
Max Ried

3
Pouvez-vous s'il vous plaît ajouter votre propre réponse, en la complétant avec plus d'explications sur les raisons pour lesquelles cela affecte potentiellement le comportement de votre terminal local, et comment dire à ssh_config de ne pas envoyer LC_ *. Parce que tu viens de -1 ma réponse sans réelle explication.
raarts

Si vous vous connectez à partir de MacOS à l'aide de Terminal, allez dans Paramètres du terminal> Avancé et décochez "Définir les variables d'environnement locales au démarrage".
javaxien le

1
Ce qui semble se produire est le suivant: sur votre système local, des paramètres régionaux ont été installés, puis vous passez sur un autre système, mais ces paramètres régionaux ne sont pas installés. Le terminal client indiquera au système distant votre environnement local et le système distant ne pourra pas répondre dans la langue demandée. Vous avez deux moyens de remédier à cela: soit vous modifiez ce qui est demandé, soit vous ajoutez les paramètres régionaux demandés au système distant (ce qui nécessite un accès root).
Jan

27

J'ai eu le même problème et j'ai ajouté les lignes ci-dessous dans mon /etc/default/localedossier:

LC_CTYPE="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
LANG="en_US.UTF-8"

Je viens de ce post: Comment puis-je résoudre mon problème de paramètres régionaux?


3
En agissant ainsi, vous vous retrouvez avec une configuration de paramètres régionaux très compliquée. /etc/environmentn'est pas destiné à la définition de paramètres régionaux dans Ubuntu; /etc/default/localeest. De plus, dans le cas d'un poste de travail, vous ne devriez jamais, jamais paramétrer de manière LC_ALLpersistante. Selon votre façon de faire, les interfaces utilisateur permettant de contrôler les paramètres de langue / paramètres régionaux sur un bureau, telles que le support de langue, deviendront inutiles.
Gunnar Hjalmarsson

Cela fonctionne réellement. Après un redémarrage.
TranslucentCloud

Déconnexion et connexion, cela devrait fonctionner
Sand1512 Le

19

seulement avec ce travail pour moi

sudo dpkg-reconfigure locales
sudo locale-gen

2
En réalité, seul sudo dpkg-reconfigure localesest nécessaire car il utilise locale-gen.
Etienne Gautier

9
export LC_ALL="en_US.UTF-8"
export LC_CTYPE="en_US.UTF-8"
sudo dpkg-reconfigure locales

Je courais une instance Vultr presque propre avec des problèmes comme dans la question, a examiné l'environnement vars et tout avait l'air bien. Cependant, sudo dpkg-reconfigure localesquelque chose qui a dû manquer. Mes sessions SSH sont maintenant OK. Merci!
Jonas

6

Le résultat de la localecommande indique que cette ligne est incorrecte dans votre environnement:

LC_CTYPE="UTF-8"

("UTF-8" n'est pas un nom de région valide.)

Cela vient généralement de /etc/default/locale. Veuillez supprimer cette ligne, si elle existe, et vous reconnecter.

S'il ne provient pas de là, il peut provenir de votre configuration de shell ou, si vous êtes connecté à distance via SSH, de la configuration de la machine cliente.


Dois-je changer LC_CTYPE en utf8?
Mave

@ Lucas: Non, ce serait tout aussi grave. Puisque LANG est défini, vous pouvez simplement supprimer la ligne entière qui commence par LC_CTYPE.
Gunnar Hjalmarsson

Si vous souhaitez définir LC_TYPE, vous devez également le définir sur "en_US.UTF-8".

Si cela provient de la configuration de la machine client, vous pouvez ajouter les paramètres régionaux sur le serveur avec dpkg-reconfigure locales.
Paul Rougieux

5

Ces commandes m'ont sauvé la vie

sudo echo "LC_ALL=en_US.UTF-8" >> /etc/environment
sudo echo "en_US.UTF-8 UTF-8" >> /etc/locale.gen
sudo echo "LANG=en_US.UTF-8" > /etc/locale.conf
sudo locale-gen en_US.UTF-8

5
Les fichiers sont ouverts avant sudo. Les redirections ne fonctionneront que si vous êtes déjà root.
Martin Thornton

3

Le fichier / etc / default / locale peut avoir des lignes supplémentaires (mais inutiles): Exemple de fichier peut ressembler à ceci:

#  File generated by update-locale
LANG=en_US.UTF-8
LANGUAGE="en_IN:en

Pour trier, générer et reconfigurer avec succès les paramètres régionaux, supprimez ou commentez toutes les lignes de ce fichier, à l'exception de:

LANG=en_US.UTF-8

Le fichier devrait enfin ressembler à:

#  File generated by update-locale
LANG=en_US.UTF-8
# LANGUAGE="en_IN:en

Après cela, exécutez dpkg-reconfigure locales, sélectionnez en_US.UTF-8 lorsque vous êtes invité à sélectionner les paramètres régionaux, et vous devriez être prêt à aller. Vous recevrez un Generation complete.message à la fin du processus.


0

J'ai réussi à faire moi - même lors de la migration des fichiers de point de répertoire de base à une nouvelle machine, et je pas permis d'identifier la cause pendant un certain temps en raison de la recherche de fichiers pour LC_mais pas LOC.

Le ~/.bashrcfichier que j'ai copié avait les éléments suivants:

export LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale

(La valeur particulière ici était due à des expériences antérieures avec GNU Guix sur l'ancienne machine; mais le fait important est simplement que la variable d'environnement a été définie sur un chemin désormais invalide.)

Cela a entraîné l'erreur suivante lors de l'exécution de divers programmes:

Warning: locale not supported by C library, locale unchanged

Et ces erreurs lors de l'exécution locale:

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

Supprimer (ou commenter) la LOCPATHligne a résolu mes problèmes.


0

Il suffit de lancer ce qui suit:

sudo apt-get upgrade

il générera tous les locats, puis définira la valeur par défaut sur US:

export LC_ALL="en_US.UTF-8"
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.