LC_CTYPE kann nicht auf das Standardgebietsschema gesetzt werden: Keine solche Datei oder kein solches Verzeichnis


54

Ich habe die genaue Frage, aber es gibt keine Lösung. Ich habe es versucht, aber es funktioniert nicht

Wie behebe ich mein Gebietsschema?

$ 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

Liegt dies an der Nichtübereinstimmung von en_US.UTF-8 und en_US.utf8?

Wie repariert man?


Haben Sie diese askubuntu.com/a/229512/387382 gelesen ?
Helio

Antworten:


53

Öffnen Sie das Terminal und geben Sie den folgenden Befehl ein:

export LC_ALL="en_US.UTF-8"

Das funktioniert, aber warum?
Yu Jiaao

16
Dies löst nichts, da die Variable am Ende der Sitzung zerstört wird.
Etienne Gautier


Tolle Lösung in so kleinen Worten. Lol!
Redbob

1
Beim Exportieren dieser Var bekomme ich:-bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
nnyby

36

Dasselbe Problem (LC_CTYPE = UTF-8, was falsch ist) kann auftreten, wenn Sie sich über ssh von einem Mac an einer Linux-Box anmelden und Ihr Terminal automatisch Umgebungsvariablen setzt. Dafür gibt es ein Kontrollkästchen. Deaktivieren Sie es und Sie können loslegen. In iTerm ist es in der Registerkarte Profil-> Terminal.


2
Deaktivieren Sie in iTerm das Kontrollkästchen "Einstellungen> Profile> Standard> Terminal> Umgebung>
Ländervariablen

1
-1: Während dies funktionieren könnte, ist es extrem invasiv. Sie haben möglicherweise auch Einfluss auf das Verhalten Ihres lokalen Terminals sowie auf das Verhalten aller Hosts, mit denen Sie eine Verbindung herstellen. Obwohl Ihre Erkenntnisse stimmen, ist es eine bessere Idee, ssh_config zu verwenden, um das LC_ * nicht an Hosts zu senden, bei denen bekanntermaßen Probleme auftreten.
Max Ried

3
Können Sie bitte Ihre eigene Antwort hinzufügen und sie mit weiteren Erläuterungen dazu erweitern, warum dies möglicherweise das Verhalten Ihres lokalen Terminals beeinflusst, und wie Sie ssh_config anweisen, LC_ * nicht zu senden. Weil du nur -1 meine Antwort ohne wirkliche Erklärung hast.
Raarts

Wenn Sie unter MacOS eine Verbindung mit Terminal herstellen, gehen Sie zu Terminaleinstellungen> Erweitert und deaktivieren Sie "Umgebungsvariablen für das Gebietsschema beim Start festlegen".
Javaxian

Was zu passieren scheint, ist: Auf Ihrem lokalen System ist ein Gebietsschema installiert, dann ssh auf ein anderes System, auf dem dieses Gebietsschema nicht installiert ist. Der Terminal-Client teilt dem Remote-System Ihre Ländereinstellung mit, und das Remote-System antwortet nicht in der angeforderten Sprache. Sie haben zwei Möglichkeiten, dies zu beheben: Entweder Sie ändern, was angefordert wird, oder Sie fügen das angeforderte Gebietsschema dem fernen System hinzu (für das Root-Zugriff erforderlich ist).
Jan

27

Ich hatte ein ähnliches Problem und fügte die folgenden Zeilen in meine /etc/default/localeDatei ein:

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

Ich habe Folgendes aus diesem Beitrag erhalten: Wie behebe ich mein Gebietsschema-Problem?


3
Auf diese Weise erhalten Sie eine sehr unübersichtliche Konfiguration des Gebietsschemas. /etc/environmentist nicht zum Einstellen von Gebietsschemas in Ubuntu vorgesehen; /etc/default/localeist. Auch im Falle eines Desktops sollten Sie niemals LC_ALLdauerhaft einstellen . Ihre Vorgehensweise macht die Benutzeroberflächen zum Steuern der Sprach- / Gebietsschemaeinstellungen auf einem Desktop (z. B. Sprachunterstützung) unbrauchbar.
Gunnar Hjalmarsson

Das funktioniert tatsächlich. Nach einem Neustart.
TranslucentCloud

Logout und Login, es sollte funktionieren
Sand1512

19

nur mit dieser arbeit für mich

sudo dpkg-reconfigure locales
sudo locale-gen

2
Eigentlich ist nur sudo dpkg-reconfigure localesnötig, da es locale-gen verwendet.
Etienne Gautier

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

Ich habe eine nahezu saubere Vultr-Instanz mit Problemen wie in der Frage ausgeführt, in die Umgebungsvariablen geschaut und alles sah in Ordnung aus. Allerdings sudo dpkg-reconfigure localeshat etwas gefehlt , was gefehlt haben muss. Meine SSH-Sitzungen sind jetzt OK. Vielen Dank!
Jonas

6

Die Ausgabe des localeBefehls zeigt an, dass Sie diese falsche Zeile in Ihrer Umgebung haben:

LC_CTYPE="UTF-8"

("UTF-8" ist kein gültiger Gebietsschemaname.)

Es kommt in der Regel aus /etc/default/locale. Bitte entfernen Sie diese Zeile, falls vorhanden, und melden Sie sich erneut an.

Wenn es nicht von dort kommt, kann es von Ihrer Shell-Konfiguration stammen, oder wenn Sie remote über SSH angemeldet sind, von der Konfiguration des Client-Computers.


Ändere ich LC_CTYPE in utf8?
Mave

@Lucas: Nein, das wäre genauso schlimm. Da LANG gesetzt ist, können Sie einfach die gesamte Zeile entfernen, die mit LC_CTYPE beginnt.
Gunnar Hjalmarsson

Wenn Sie LC_TYPE festlegen möchten, sollten Sie es auch auf "en_US.UTF-8" festlegen.

Wenn es aus der Konfiguration des Clientcomputers stammt, können Sie das Gebietsschema auf dem Server mit hinzufügen dpkg-reconfigure locales.
Paul Rougieux

5

Diese Befehle haben mir das Leben gerettet

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
Dateien werden vorher geöffnet sudo. Die Weiterleitungen funktionieren nur, wenn Sie bereits als Root angemeldet waren.
Martin Thornton

3

Die Datei / etc / default / locale kann zusätzliche (aber unnötige) Zeilen enthalten: Die Beispieldatei kann folgendermaßen aussehen:

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

Entfernen oder kommentieren Sie alle Zeilen aus dieser Datei, um Gebietsschemas zu sortieren und erfolgreich zu generieren und neu zu konfigurieren, mit Ausnahme von:

LANG=en_US.UTF-8

Die Datei sollte nun endlich so aussehen:

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

Führen dpkg-reconfigure localesSie anschließend den Befehl en_US.UTF-8 aus, wenn Sie zur Auswahl des Gebietsschemas aufgefordert werden. Sie erhalten eine Generation complete.Nachricht, wenn der Vorgang abgeschlossen ist.


0

Ich habe es selbst geschafft, dies zu verursachen, als ich die Dot-Dateien des Ausgangsverzeichnisses auf einen neuen Computer migrierte, und ich konnte die Ursache für eine Weile nicht identifizieren, da ich nach Dateien gesucht habe, LC_aber nicht LOC.

Die von ~/.bashrcmir kopierte Datei hatte folgendes:

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

(Der besondere Wert hier war auf frühere Experimente mit GNU Guix auf der alten Maschine zurückzuführen; die relevante Tatsache ist jedoch lediglich, dass die Umgebungsvariable auf einen jetzt ungültigen Pfad gesetzt wurde.)

Dies führte beim Ausführen verschiedener Programme zu folgendem Fehler:

Warning: locale not supported by C library, locale unchanged

Und diese Fehler beim Laufen 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

Durch Entfernen (oder Auskommentieren) der LOCPATHZeile wurden meine Probleme behoben.


0

führe einfach folgendes aus:

sudo apt-get upgrade

es werden alle Locates generiert und dann der Standard auf US gesetzt:

export LC_ALL="en_US.UTF-8"
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.