Comment faire en sorte que le shell de login xterm utilise utf-8?

J'utilise xterm (X-Win32 2012 Build 30 de StarNet Communications Corp) pour se connecter depuis un PC Windows 7 à un Red Enterprise Linux 6 (RHEL6).

Mon problème est que tous les caractères multi-octets utf-8 sortent brouillés dans le shell de connection xterm. Par exemple, voici comment la string "Wilhelm Röntgen" est rendue dans les deux instances de shell (la police utilisée est une police Unicode et la même police dans les deux instances de shell):

Login shell: Wilhelm Röntgen Second shell: Wilhelm Röntgen 

Si j'ai bien compris, le logiciel de StarNet Communications Corp implémente (ou émule) un terminal X (un client léger qui exécute un server X). C'est-à-dire que les deux instances de shell s'exécutent dans une window de terminal X sur le PC et communiquent avec RHEL6 en utilisant le protocole X11. Voici comment les deux coquilles apparaissent sur mon bureau, catenant un file avec des caractères unicode multibye au terminal.

entrer la description de l'image ici

Voici la command que j'ai configurée avec X-Win32 pour lancer le shell de connection:

 xterm -u8 -ls 

Cependant, après avoir ouvert une session, je peux faire xterm dans le shell de connection, et cette command va fourrer une nouvelle instance de xterm où les parameters régionaux fonctionnent comme prévu (c'est-à-dire que les caractères utf-8 sont rendus correctement).

Voici les parameters pertinents tels qu'ils apparaissent dans le shell de connection:

 $ 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 

J'ai aussi les deux lignes suivantes dans .Xressources:

 xterm*locale: true xterm*utf8: 1 

Il semble que le shell de connection xterm ne reconnaisse pas les parameters régionaux que j'ai définis, mais je ne comprends pas pourquoi. Mon xterm est clairement capable de cela, puisque tous les shells non-login le font par défaut.

Au moment où le process sshd sur l'ordinateur distant forks / run / usr / bin / xterm il y a très peu de variables d'environnement définies. En fait, la variable LANG n'est pas définie. Par conséquent, le process xterm ne sait pas qu'il doit afficher les caractères en UTF-8. Il retombe à xterms par défaut. Quoi que cela puisse être.

Cependant, le sous-shell exécuté dans le xterm exécute tous les scripts d'installation et similaires. Y compris la définition de la variable d'environnement LANG.

Il faut comprendre la différence entre le process xterm distant et le process shell qui s'exécute à l'intérieur de xterm.

La solution consiste à exécuter le process distant xterm comme ceci:

 /usr/bin/env LANG=en_US.UTF-8 /usr/bin/xterm 

env (1) est un utilitaire permettant d'exécuter un programme dans un environnement modifié.

La configuration de LANG fera l'affichage correct des caractères UTF-8 à distance.

Eskil … 🙂

Ps: Lecture de la page de manuel de xterm J'ai aussi trouvé un moyen plus facile de réaliser ceci:

xterm -en en_US.UTF-8

PPs: Je ne pense pas que l'établissement de ressources dans ~ / .Xresources prendra effet à less que vous ne les fusionniez avec xrdb. Le process xterm sur l'ordinateur Linux interrogera le server X s'exécutant sur votre ordinateur Windows. Au moment où xterm démarre, il est très peu probable que votre server X-Win32 dispose des ressources xterm *. Mais vous pourriez être en mesure de définir des ressources dans X-Win32 s'il prend en charge cela.

Je pense que vous ne dites pas à xterm d'utiliser une police Unicode. Je vois que vous utilisez un xterm-comstackd-for-Windows ou quelque chose, mais sous Arch (et d'autres dissortingbutions) lors de l'exécution d'un xterm réel , je commence comme ceci:

 xterm -u8 -fn '-misc-fixed-bold-r-normal--15-140-75-75-c-90-iso10646-1' 

Un autre émulateur de terminal Windows, PuTTY , semble assez bon pour montrer UTF-8. Si vous êtes autorisé, vous devez mettre PuTTY, le configurer pour utiliser un jeu de caractères UTF-8 et vous connecter au server Red Hat. Si PuTTY rend correctement les caractères UTF-8 à plusieurs octets, vous savez que le problème ne se situe pas du côté server, mais plutôt dans l'émulateur de terminal.

La question et les commentaires de suivi indiquent une certaine confusion. Selon l'article de la base de connaissances de StarNet Où est mon émulateur de terminal?

X-Win32 est un server X dont l'objective principal est d'afficher des applications charts à distance. La plupart des systèmes Unix / Linux modernes ont un émulateur de terminal basé sur X inclus dans les bibliothèques X. En tant que tel, X-Win32 n'en inclut pas un par défaut.

Un commentaire ajouté à la question par @ bruce-ediger indique que

Je ne pense pas qu'aucun process xterm ne soit jamais en cours d'exécution sur le server RHEL. 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. Le X-Win32 de StarNet Comm. Corp. transforme mon PC en un terminal X et les deux instances xterm s'exécutent sur le PC en utilisant le protocole X.11 pour communiquer avec les instances ssh sur RHEL6. Du less, c'est comme ça que je pense que X11 fonctionne.

Mais ce n'est pas ainsi que cela fonctionne. Le process xterm démarré sur le server RHEL s'exécute sur ce server. Il communique avec le server StarNet X (X-Win32), mais le process xterm rest là où il a été démarré.

La façon la plus simple de démarrer xterm à l'aide d'UTF-8 est d' uxterm script uxterm (qui fait partie du même packageage qui inclut xterm et ses files de ressources). Selon la FAQ xterm décrivant uxterm :

XTerm ne définit pas automatiquement vos parameters régionaux. Il peut être dit d'utiliser vos parameters régionaux. Il s'agit d'un script shell qui définit les ressources de xterm pour utiliser le encoding UTF-8 et utilise les fonts UTF-8. Il existe un script lxterm similaire, mais il repose sur des applications non portables, contrairement à uxterm .

Comme indiqué dans d'autres commentaires, vos variables d'environnement lors de la connection peuvent ne pas avoir suffisamment d'informations pour démarrer automatiquement xterm avec le encoding UTF-8 (et les fonts). Cela est fait par le script uxterm .