CentOS 6 und Gebietsschemafehler


16

Ich habe gerade CentOS 6 installiert und erhalte bei jeder Remote-Anmeldung über SSH den folgenden Fehler:

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

Wenn ich "locale" in die Befehlszeile eingebe, erhalte ich die folgende Ausgabe:

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=

Woran kann das liegen? Wie kann ich dieses Problem lösen?


Ihre Lösung zum Auskommentieren des Arguments "SendEnv LANG LC_ *" funktionierte für mich unter Mac OS X 10.7.5

Antworten:


10

Haben Sie auf dem Server, von dem Sie ssh verwenden, ein Gebietsschema über eine Umgebungsvariable festgelegt? Wenn ich meine CentOS 6-Installation betrachte, wird das einzige Gebietsschema, das ich als unterstützt finde, als en_US.utf8(mit dem locale -aBefehl ermittelt) identifiziert . Könnte dies das Problem sein?

Als ich in meinem Test die LC_ALLUmgebungsvariable auf " en_US.UTF-8ssh'd to the server" stellte, wurde POSIXin meinem Fall die Ausgabe meines Gebietsschemabefehls auf " ssh'd to the server" gesetzt . Dies ist dasselbe, als hätte ich die LC_ALLVariable vor dem ssh'ing NICHT gesetzt (dh aufgehoben).

Wenn ich meine LC_ALLVariable auf en_US.utf8oder en_US.utf-8auf meine CentOS 6-Box setze, stimmt die Ausgabe des Gebietsschemas mit der Ausgabe der Quellbox überein.

Beachten Sie, dass ich für UTF auch keine Caps verwendet habe.


11
Übrigens ist mir aufgefallen, dass dies in den SSH-Einstellungen meines Mac OS X Lion geschieht. Ich habe die Datei / etc / ssh_config bearbeitet und SendEnv LANG LC_ * kommentiert. Es hat mein Problem gelöst.
Cem

@Cem Danke für den Tipp, das behebt es in der Tat unter Mac OS X Lion.
Zsolt Török

17

Dies wurde behoben, indem "Umgebungsvariablen für das Gebietsschema beim Start festlegen" in den Terminaleinstellungen> Erweitert deaktiviert wurde (siehe Abbildung).

Bildbeschreibung hier eingeben

HINWEIS: Wenn Sie iTerm2 verwenden, können Sie die Option "Gebietsschemavariablen automatisch festlegen" unter Einstellungen> Profile> Terminal deaktivieren


1
Das hat bei mir funktioniert. Insbesondere hat Terminal.app "LC_CTYPE = UTF-8" gesetzt, was dann die vom OP gemeldeten Fehler verursachte. Alternativ unset LC_CTYPEoder export LC_CTYPE=en_US.UTF-8Behebung des Problems nach der Anmeldung.
2.

Dies löste es für mich, thx
pjvds

11

Einfacher Weg:

Hinzufügen

 LC_CTYPE="en_US.UTF-8"

zu /etc/sysconfig/i18n.


Es funktioniert bei mir nach so vielen Versuchen.
Tommy

2

Was für mich funktionierte, war das Hinzufügen eines Symlinks auf dem CentOS-Server:

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

Sobald Sie dies getan haben, funktionieren die folgenden Befehle:

export LC_CTYPE=UTF-8

Wenn Sie dies nicht tun, schlägt der letzte Befehl mit dem folgenden Fehler fehl:

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

Eine noch einfachere Lösung besteht darin, die folgende Zeile zu / etc / bashrc auf dem Server hinzuzufügen:

export LC_CTYPE="en_US.utf8"

Danke für die Eingabe! das hat super geklappt. Endlich in der Lage, diesen nervigen Kommentar zu entfernen ...
Cristobal

2

Ich habe diese spezielle Meldung erhalten, wenn ich mich von einem Solaris X auf einem Centos-Host anmelde.

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

Das Problem kommt von 2 Einstellungen:

  1. In meinem Standardsystem ssh_config fordere ich das System auf, diese Variablen zu übergeben.

Gebietsschemabezogene Umgebungsvariablen senden SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES

  1. Auf meinem Quellhost wurden diese Einstellungen folgendermaßen festgelegt:

    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

Wie Sie jedoch sehen können, ist LC_MESSAGES auf fr.UTF-8 eingestellt, was auf meinem Zielhost keine Option ist.

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

Das Problem wurde auf meinem Quellhost unter .bash_profile behoben: # export LC_ALL = fr_FR.UTF-8 export LANG = fr_FR.UTF-8

Ich hätte es lösen können, indem ich meinen Zielhost gebeten hätte, diese Variable nicht von einer SSH-Verbindung zu nehmen (im Allgemeinen oder indem ich eine ssh_config-Datei für meinen Benutzer erstellt hätte).


1

Auf einem lokalen Centos 6.2-System: Dies hat nicht geholfen:

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

Das hat funktioniert:

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

Ich löschte auch locale-archivein /usr/lib/locale. Ich weiß nicht, ob das nötig war.


1

Dies war in der Vergangenheit meine Korrektur für Gebietsschemafehler.

Führen Sie Folgendes aus: locale-gen

Dann editiere /etc/locale.gen. Stellen Sie sicher, dass Folgendes nicht kommentiert ist:

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

generate locale

locale-gen

1

Bei Iterm2 ist das anders.
Gehen Sie zu Iterm2 -> Preferencesund dann zur ProfilesRegisterkarte und wählen Sie die TerminalRegisterkarte unten aus.
Gehen Sie zur EnvironmentKategorie und heben Sie die Markierung auf.

Gebietsschemavariablen automatisch festlegen

Schließen Sie abschließend eine neue Sitzung und starten Sie sie.

Bildbeschreibung hier eingeben


0

und stellen Sie sicher, dass LC_ALL="en_US.UTF-8"es sich in / etc / sysconifg / i18n befindet oder hinzugefügt wurde

Beispiel Inhalt

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

-3

bearbeiten /etc/sysconfig/i18n

Wechseln Sie LANG="us"zuLANG="en_US"

Speichern und beenden, abmelden und wieder anmelden.

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.