ich benutzexterm(X-Win32 2012 Build 30 von StarNet Communications Corp), um sich von einem Windows 7-PC bei einem Red Enterprise Linux 6 (RHEL6) anzumelden.
Mein Problem ist, dass alle Multibyte-UTF-8-Zeichen in der Xterm-Login-Shell verstümmelt ausgegeben werden. So wird beispielsweise die Zeichenfolge „Wilhelm Röntgen“ in den beiden Shell-Instanzen wiedergegeben (die verwendete Schriftart ist eine Unicode-Schriftart und in beiden Shell-Instanzen dieselbe Schriftart):
Login shell: Wilhelm Röntgen
Second shell: Wilhelm Röntgen
Wenn ich das richtig verstanden habe, implementiert (oder emuliert) die Software von StarNet Communications Corp ein X-Terminal (einen Thin Client, der einen X-Server ausführt). D. h. beide Shell-Instanzen laufen in einem X-Terminalfenster auf dem PC und kommunizieren mit RHEL6 über das X11-Protokoll. Unten sehen Sie, wie beide Shells auf meinem Desktop erscheinen und eine Datei mit Unicode-Mehrbytezeichen an das Terminal anhängen.
Hier ist der Befehl, den ich für den Start der Login-Shell in X-Win32 konfiguriert habe:
xterm -u8 -ls
Jedoch,nachIch melde mich an. Ich kann dies xtermin der Anmeldeshell tun und dieser Befehl führt eine neue XTerm-Instanz aus, in der die Gebietsschemaeinstellungen wie erwartet funktionieren (d. h. UTF-8-Zeichen werden korrekt gerendert).
Hier sind die relevanten Einstellungen, wie sie in der Login-Shell angezeigt werden:
$ locale
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE=C
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=
$ printenv XTERM_LOCALE
en_US.UTF-8
Ich habe auch die folgenden zwei Zeilen in .Xresources:
xterm*locale: true
xterm*utf8: 1
Es sieht so aus, als ob die Login-Shell xterm das von mir eingestellte Gebietsschema nicht erkennt, aber ich verstehe nicht, warum das nicht so ist. Mein xterm ist dazu offensichtlich in der Lage, da alle Nicht-Login-Shells dies standardmäßig tun.
Antwort1
Wenn der SSHD-Prozess auf dem Remotecomputer abzweigt, um /usr/bin/xterm auszuführen, sind nur sehr wenige Umgebungsvariablen gesetzt. Tatsächlich ist die Variable LANG nicht gesetzt. Daher weiß der xterm-Prozess nicht, dass er Zeichen in UTF-8 anzeigen soll. Er greift auf die xterm-Standardeinstellungen zurück. Was auch immer das sein mag.
Die innerhalb von xterm ausgeführte Subshell führt jedoch alle Setup-Skripte usw. aus. Einschließlich der Einstellung der Umgebungsvariable LANG.
Man muss den Unterschied zwischen dem Remote-xterm-Prozess und dem Shell-Prozess verstehen, der innerhalb von xterm ausgeführt wird.
Die Lösung besteht darin, den Remote-Xterm-Prozess wie folgt auszuführen:
/usr/bin/env LANG=en_US.UTF-8 /usr/bin/xterm
env(1) ist ein Dienstprogramm zum Ausführen eines Programms in einer geänderten Umgebung.
Durch die Einstellung von LANG wird das Remote-Xterm dazu veranlasst, UTF-8-Zeichen richtig anzuzeigen.
Eskil... :-)
P.S.: Beim Lesen der xterm-Manpage habe ich auch einen einfacheren Weg gefunden, dies zu erreichen:
xterm -en en_US.UTF-8
PPs: Ich glaube nicht, dass das Festlegen von Ressourcen in ~/.Xresources wirksam wird, es sei denn, Sie führen sie mit xrdb zusammen. Der xterm-Prozess auf dem Linux-Computer fragt den X-Server ab, der auf Ihrem Windows-Computer ausgeführt wird. Zum Zeitpunkt des Starts von xterm ist es sehr unwahrscheinlich, dass Ihr X-Win32-Server die xterm*-Ressourcen festgelegt hat. Sie können jedoch möglicherweise Ressourcen in X-Win32 festlegen, wenn dies unterstützt wird.
Antwort2
Ich glaube nicht, dass Sie xtermeine Unicode-Schriftart verwenden sollen. Ich sehe, dass Sie eine für Windows kompilierte xterm-Datei oder so etwas verwenden, aber unter Arch (und anderen Distributionen) beim Ausführen einesrealxterm, ich starte es so:
xterm -u8 -fn '-misc-fixed-bold-r-normal--15-140-75-75-c-90-iso10646-1'
Ein weiterer Windows-Terminalemulator,Kitt, scheint UTF-8 ziemlich gut darzustellen. Wenn Sie dazu berechtigt sind, sollten Sie PuTTY installieren, die Verwendung eines UTF-8-Zeichensatzes einstellen und eine Verbindung zum Red Hat-Server herstellen. Wenn PuTTY mehrbytegroße UTF-8-Zeichen korrekt rendert, wissen Sie, dass das Problem nicht auf der Serverseite, sondern beim Terminalemulator liegt.
Antwort3
Die Frage und die Folgekommentare deuten auf eine gewisse Verwirrung hin. Laut dem Knowledgebase-Artikel von StarNetWo ist mein Terminalemulator?
X-Win32 ist ein X-Server, dessen Hauptzweck die Anzeige von Remote-Grafikanwendungen ist. Die meisten modernen Unix/Linux-Systeme haben einen X-basierten Terminalemulator in den X-Bibliotheken. Daher enthält X-Win32 standardmäßig keinen.
Ein von @bruce-ediger zur Frage hinzugefügter Kommentar besagt, dass
Ich glaube nicht, dass auf dem RHEL-Server jemals ein Xterm-Prozess ausgeführt wird.
When I type in xterm in the shell on RHEL, all it does is to send a message to the X windows server on the PC, requesting that it creates another xterm process/window.X-Win32 von StarNet Comm. Corp. verwandelt meinen PC in ein X-Terminal, und beide Xterm-Instanzen werden auf dem PC ausgeführt, wobei das X.11-Protokoll zur Kommunikation mit den SSH-Instanzen auf RHEL6 verwendet wird. Zumindest glaube ich, dass X11 so funktioniert.
Aber so funktioniert es nicht. Der auf dem RHEL-Server gestartete xterm-Prozess läuftAndieser Server. Er kommuniziert mit dem StarNet X-Server (X-Win32), aber der xterm-Prozess bleibt dort, wo er gestartet wurde.
Der einfachste Weg, xterm mit UTF-8 zu starten, ist über denuxtermSkript (das Teil desselben Pakets ist, das auch enthältxtermund seine Ressourcendateien). Laut derHäufig gestellte Fragen zu xtermBeschreibunguxterm:
XTermlegt Ihr Gebietsschema nicht automatisch fest. Es kann angewiesen werden, Ihre Gebietsschemaeinstellungen zu verwenden. Dies ist ein Shell-Skript, das die Ressourcen von xterm so einstellt, dass sie UTF-8-Kodierung und UTF-8-Schriftarten verwenden. Es gibt ein ähnliches
lxtermSkript, aber es basiert auf nicht portablen Anwendungen, im Gegensatz zuuxterm.
Wie in anderen Kommentaren erwähnt, verfügen Ihre Umgebungsvariablen beim Anmelden möglicherweise nicht über genügend Informationen, um zu startenxtermautomatisch mit UTF-8-Kodierung (und Schriftarten). Dies wird durch dieuxtermSkript.