Lösung für „Keine solche Datei oder kein solches Verzeichnis“ im Gebietsschema nach der Installation von glibc-2.14 in CentOS6.5

1. In die Grube fallen

Vor kurzem musste ein Testserver (CentOS6.5) innerhalb des Unternehmens die glibc-Bibliothek aktualisieren, um eine bestimmte Software zu installieren. glibc ist eine Kernbibliothek von Linux. Wenn die Originalversion direkt ersetzt und aktualisiert wird, können unvorhersehbare Ausnahmen auftreten (z. B. können viele Befehle nicht ausgeführt werden).
Ich habe glibc-2.14 also manuell aktualisiert und installiert, wobei ich mich an den Prozess zum Aktualisieren von glibc in Centos6.5 gehalten habe. <br /> Ich habe das Tarball von glibc-2.14 von der offiziellen Website heruntergeladen und es gemäß den obigen Schritten kompiliert und installiert:

$ mkdir build // Erstellen Sie einen Build-Ordner im Verzeichnis glibc-2.14$ cd build // Wechseln Sie in das Build-Verzeichnis$ ../configure --prefix=/opt/glibc-2.14 // Hinweis: Konfigurieren Sie glibc und legen Sie das aktuelle Installationsverzeichnis von glibc-2.14 fest$ make && make install // Kompilieren und installieren Sie die Bibliothek glibc-2.14

Nach dem Ändern des Softlinks, der auf /lib64/libc.so.6 verweist, kann das Programm normal ausgeführt werden, aber die chinesischen Schriftzeichen sind verstümmelt .

Aus meiner eigenen Erfahrung und den Meinungen der meisten Leute im Internet halte ich das für ganz einfach. Kann ich nicht einfach die Sprache zurücksetzen und das Problem wird behoben?

Tun Sie es einfach, führen Sie „locale“ in der Shell aus, und der folgende Fehler tritt auf:

Gebietsschema: LC_CTYPE kann nicht auf Standardgebietsschema eingestellt werden: Keine solche Datei oder kein solches Verzeichnis
Gebietsschema: LC_ALL kann nicht auf Standardgebietsschema eingestellt werden: Keine solche Datei oder kein solches Verzeichnis

_Hinweis: Der obige Fehler tritt nicht nur beim manuellen Ausführen des Locale-Befehls auf, sondern auch jedes Mal, wenn Sie sich remote über SSH bei der Shell anmelden. _

2. Vergeblich kämpfen

Um das obige Problem zu lösen, habe ich viel auf Baidu und G-Dog gesucht und die folgenden Methoden ausprobiert, aber das Problem besteht weiterhin.

Verwenden Sie den folgenden Befehl:
export LANG="en_US.utf8"
Sie können die Umgebungsvariable LANG ändern. Die Änderung wird sofort wirksam. Beim Neustart des Systems wird die Sprache auf die ursprüngliche Sprache zurückgesetzt. Es gibt zwei weitere Möglichkeiten, die Sprache zu ändern:
1. Konfigurieren Sie die folgenden Dateien:
vi /etc/sysconfig/i18n
Ändern Sie die ursprüngliche Konfiguration wie folgt:
LANG="zh_CN.utf8"
Ändern Sie in LANG="en_US.utf8"
Nach dem Speichern wird es nicht sofort wirksam, sondern erst nach einem Neustart.

3. Der Impuls der Jugend

Als ich in Panik geriet, ging ich kurz raus, um zu rauchen. Ich sollte wohl auf den Kern des Problems zurückkommen. Da der Fehler „Keine solche Datei oder kein solches Verzeichnis“ angezeigt wurde, bedeutet dies, dass wir ein Gebietsschema konfiguriert haben, das nicht existiert oder vom System nicht unterstützt wird. Beispielsweise wird in der obigen Lösung durch Ändern der Sprache LANG="en_US.UTF-8" das Gebietsschema auf zh_CN.UTF-8 eingestellt. Als das Betriebssystem die Lokalisierungsumgebung über die Konfiguration initialisierte, fand es das entsprechende Sprachpaket nicht (tatsächlich ist es nicht nur das Sprachpaket, das Gebietsschema umfasst auch Zeitzone, Währungsmaß usw.), d. h. das Betriebssystem kann die entsprechende Gebietsschemadatei nicht finden. Wenn Sie dieses Problem verstehen, ist es leicht zu lösen.

Verwenden Sie zunächst den Befehl „locale“, um zu prüfen, ob dieses Gebietsschema im System vorhanden ist

[****@****** bin]# locale -a|grep en_US
de_DE
de_US.iso88591
de_US.iso885915
de_DE.utf8

Ich war fassungslos, als ich es sah. Es enthält en_US.utf8, was bedeutet, dass das Betriebssystem die Konfiguration des Gebietsschemas auf en_US.utf8 unterstützt. Warum erscheint dann immer noch der folgende Fehler:

Gebietsschema: LC_CTYPE kann nicht auf Standardgebietsschema eingestellt werden: Keine solche Datei oder kein solches Verzeichnis
Gebietsschema: LC_ALL kann nicht auf Standardgebietsschema eingestellt werden: Keine solche Datei oder kein solches Verzeichnis

4. Ein Hoffnungsschimmer

Haben Sie etwas übersehen? Gehen Sie zurück zum Ausgangspunkt und prüfen Sie es noch einmal. Plötzlich kam mir eine Frage in den Sinn: Wir haben eine neue glibc-Bibliothek neu installiert, anstatt das Upgrade zu überschreiben, was bedeutet, dass es im System mindestens zwei Locale-Befehle gibt. Woher weiß CentOS, welcher zu verwenden ist?

Könnte es sein, dass unser neu installiertes /opt/glibc-2.14/bin/locale anstelle des Systemstandards /usr/bin/locale verwendet wird? Diese Annahme lässt sich leicht mit dem folgenden Befehl überprüfen:

[****@****** bin]# /opt/glibc-2.14/bin/locale -a 
C
POSIX

Natürlich unterstützt dieses Gebietsschema nur C und POSIX, aber nicht en_US.utf8. Wenn wir also das Gebietsschema auf en_US.utf8 konfigurieren, wird natürlich der Fehler „Datei oder Verzeichnis nicht vorhanden“ gemeldet.

Die Frage ist, woher die lokalisierten Sprachpakete stammen, die im Befehl /opt/glibc-2.14/bin/locale aufgelistet sind? Über eine Konfigurationsdatei? Oder die Dateien direkt in einem Verzeichnis lesen?
Wenn Sie sich den Quellcode ansehen, ist es natürlich einfach, die Antwort auf die obige Frage zu finden. Da ich faul bin, wage ich eine mutige Vermutung: Es sollte aus einem bestimmten Verzeichnis gelesen werden, das alle vom System unterstützten Lokalisierungsdateien enthalten sollte. Diese Vermutung ergibt sich aus der Fehlermeldung „keine solche Datei oder kein solches Verzeichnis“.

Um den Speicherort dieses Verzeichnisses zu finden, habe ich an den Strings-Befehl gedacht und direkt den folgenden Befehl verwendet:

[****@****** bin]# Zeichenfolgen /opt/glibc-2.14/bin/locale|grep locale
Gebietsschema festlegen
/Gebietsschema.
Gebietsschema (GNU %s) %s
/opt/glibc-2.14/lib/locale
/opt/glibc-2.14/share/locale
alle Gebietsschemas
/opt/glibc-2.14/lib/locale/locale-archive
Gebietsschema: %-15.15s Archiv: /opt/glibc-2.14/lib/locale/locale-archive
Gebietsschema: %-15.15s Verzeichnis: %.*s
LC_CTYPE kann nicht auf Standardgebietsschema eingestellt werden
LC_MESSAGES kann nicht auf Standardgebietsschema eingestellt werden
LC_COLLATE kann nicht auf Standardgebietsschema eingestellt werden
LC_ALL kann nicht auf Standardgebietsschema eingestellt werden
Schreiben Sie die Namen der verfügbaren Gebietsschemas
Erhalten Sie länderspezifische Informationen.

Tatsächlich gibt es einen Pfad /opt/glibc-2.14/lib/locale/locale-archive . Aus dem Namen lässt sich leicht erraten, dass dies wahrscheinlich der Locale-Befehl zum Lesen des Speicherorts aller unterstützten Locale-Verzeichnisse (oder Archivdateien) ist.

5. Problem KO

Ein Blick auf das obige Verzeichnis zeigt, dass es tatsächlich leer ist und keine Archivdatei mit dem Namen „Locale-Archive“ vorhanden ist.

[****@****** bin]# ll /opt/glibc-2.14/lib/locale/

Die Lösung ist ganz einfach. Kopieren Sie einfach die Locale-Archivdatei, die vom Locale-Befehl /usr/bin/locale verwendet wird, nach /opt/glibc-2.14/lib/locale/locale-archive

[****@****** bin]# cp /usr/lib/locale/locale-archive /opt/glibc-2.14/lib/locale/locale-archive

Manche Freunde fragen sich vielleicht, woher Sie wissen, dass das von /usr/bin/locale verwendete Gebietsschemadateiverzeichnis /usr/lib/locale/locale-archive ist. Die Antwort ist einfach: Verwenden Sie Baidu und es ist leicht zu finden.

Nachdem der Kopiervorgang abgeschlossen ist, beenden Sie die Sitzung, melden Sie sich erneut an und führen Sie den Befehl /opt/glibc-2.14/bin/locale erneut aus. Der Fehler „Keine solche Datei oder kein solches Verzeichnis“ wird nicht mehr angezeigt und das vorherige Problem mit verstümmelten Zeichen ist ebenfalls gelöst.

6. Nachtrag

Oben ist beschrieben, wie ich das Problem des verstümmelten Codes gelöst habe, nachdem ich die glibc-Bibliothek manuell in der CentOS 6.5-Umgebung installiert hatte. Der Vorgang erforderte einige Kenntnisse über die Prinzipien des Gebietsschemas, die ich mir übrigens auch angeeignet habe.
Übrigens wurde der lokale Lesepfad des Befehls /opt/glibc-2.14/bin/locale oben erraten. Später habe ich mir den Quellcode von locale.c angesehen und bestätigt, dass er tatsächlich aus /opt/glibc-2.14/lib/locale/locale-archive gelesen wurde (es gibt natürlich auch andere Lesespeicherorte).

Dies ist das Ende dieses Artikels zur Lösung des Problems „Keine solche Datei oder kein solches Verzeichnis“ in der Locale nach der Installation von glibc-2.14 auf CentOS6.5. Weitere Informationen zur Lösung des Problems verstümmelter chinesischer Schriftzeichen nach der Installation von glibc finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder durchsuchen Sie die verwandten Artikel weiter unten. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!