Forum général.général ssh, vim , less et les autres

Posté par  .
Étiquettes :
0
30
sept.
2004
bon(jour|soir),

Lorsque que je me connecte à une machine fedora core 1 depuis gentoo avec ssh, je peux taper dans le shell sur les touches éàè et ça m'affiche éàè, mais si j'ouvre vim, les touches propres au français, ne marchent pas ou donne des 'ç'.
'man','less' et 'mc' ne s'affichent pas correctement.

Sur la FC1:
echo $LANG
fr_CH.UTF-8

echo $LANGVAR
fr_CH.UTF-8

Sous ma Gentoo, $LANG et $LANGVAR ne sont pas défini, mais le clavier marche avec les accents. Dans mon /etc/X11/xorg.conf, il y a:
Option "XkbLayout" "fr_CH"


Si je me connecte à un machine debian avec $LANG=C, je ne peux pas taper des caractères accentués dans le shell, mais je le peux dans vim.

Sous Windows avec Putty, il me semble qu'on peut modifier le charset, peut-on faire la même chose avec konsole?

  • # LC_ALL ?

    Posté par  . Évalué à 1.

    Pour ma part, il me semble que je me contente de la variable d'environnement LC_ALL.
    Ton problème peut venir des polices utilisées... jette un oeil de ce côté là.

  • # variables

    Posté par  (site web personnel) . Évalué à 3.

    LANGVAR n'est pas standard. LANG est utilisé mais seulement si LC_ALL n'est pas là et le LC_.. demandé non plus (le .. dépend de ce qu'on cherche : dans ton cas c'est LC_CTYPE qui détermine le codage à utiliser).

    fais "locale" pour voir LANG et tous les LC_* et LC_ALL (LC_ALL a la précédence sur eux quand il est défini). il faut rajouter LANGUAGE qui a la précédence (il me semble) sur LC_MESSAGES et permet de spécifier une liste au lieu d'une seule valeur (mais c'est une extension, GNU je pense).

    • [^] # Re: variables

      Posté par  . Évalué à 1.

      Mon gentoo resemble à ça:
      LANG=
      LC_CTYPE="POSIX"
      LC_NUMERIC="POSIX"
      LC_TIME="POSIX"
      LC_COLLATE="POSIX"
      LC_MONETARY="POSIX"
      LC_MESSAGES="POSIX"
      LC_PAPER="POSIX"
      LC_NAME="POSIX"
      LC_ADDRESS="POSIX"
      LC_TELEPHONE="POSIX"
      LC_MEASUREMENT="POSIX"
      LC_IDENTIFICATION="POSIX"
      LC_ALL=
      le pc FC1 ressemble à ça:
      LANG=fr_CH.UTF-8
      LC_CTYPE="fr_CH.UTF-8"
      LC_NUMERIC="fr_CH.UTF-8"
      LC_TIME="fr_CH.UTF-8"
      LC_COLLATE="fr_CH.UTF-8"
      LC_MONETARY="fr_CH.UTF-8"
      LC_MESSAGES="fr_CH.UTF-8"
      LC_PAPER="fr_CH.UTF-8"
      LC_NAME="fr_CH.UTF-8"
      LC_ADDRESS="fr_CH.UTF-8"
      LC_TELEPHONE="fr_CH.UTF-8"
      LC_MEASUREMENT="fr_CH.UTF-8"
      LC_IDENTIFICATION="fr_CH.UTF-8"
      LC_ALL=
      le pc debian

      LANG=C
      LC_CTYPE="C"
      LC_NUMERIC="C"
      LC_TIME="C"
      LC_COLLATE="C"
      LC_MONETARY="C"
      LC_MESSAGES="C"
      LC_PAPER="C"
      LC_NAME="C"
      LC_ADDRESS="C"
      LC_TELEPHONE="C"
      LC_MEASUREMENT="C"
      LC_IDENTIFICATION="C"
      LC_ALL=

      en faisant export LC_ALL="POSIX", sur la machine FC1, j'arrive à écrire. Mais man coince en disant:
      iconv: illegal input sequence at position 135

      Comment fait-on pour installer le fr_CH.utf8 sur gentoo (Je pourrais copier ce qu'il y a sur FC1, mais je ne trouve pas ça très propre, en plus ce n'est pas reproductible si on a pas de FC sous la main, à moins qu'il n'ait que FC qui utilse ça *.utf8 )?
      Sur FC1, locate fr_CH.utf8 donne:
      /usr/lib/locale/fr_CH.utf8
      /usr/lib/locale/fr_CH.utf8/LC_MESSAGES
      /usr/lib/locale/fr_CH.utf8/LC_MESSAGES/SYS_LC_MESSAGES
      /usr/lib/locale/fr_CH.utf8/LC_TIME
      /usr/lib/locale/fr_CH.utf8/LC_IDENTIFICATION
      /usr/lib/locale/fr_CH.utf8/LC_TELEPHONE
      /usr/lib/locale/fr_CH.utf8/LC_MONETARY
      /usr/lib/locale/fr_CH.utf8/LC_CTYPE
      /usr/lib/locale/fr_CH.utf8/LC_NUMERIC
      /usr/lib/locale/fr_CH.utf8/LC_NAME
      /usr/lib/locale/fr_CH.utf8/LC_ADDRESS
      /usr/lib/locale/fr_CH.utf8/LC_PAPER
      /usr/lib/locale/fr_CH.utf8/LC_MEASUREMENT
      /usr/lib/locale/fr_CH.utf8/LC_COLLATE

      alors que sous ma gentoo rien.

      • [^] # Re: variables

        Posté par  . Évalué à 3.

        Bon, tes deux systèmes n'utilisent pas le même codage de caractère (utf-8 unicode pour fedora, et probablement iso-8859-1 pour gentoo) donc il est possible que la sortie de l'un soit mal interpreté par l'autre (un peu comme les pages webs en chinois qui ne spécifient pas le charset, ton browser occidental par défaut te crache des accents tordus à la place)

        Pour rappelle, UTF8 encode les caractères qui sortent de l'ASCII-7 avec plusieurs octets, d'où les 2 caractères ç à la place du é.

        Je ne sais pas vraiment pourquoi dans un shell c'est converti proprement, et pas dans vim...

        je ne pense pas qu'"installer des locales" sous gentoo regle le problème (à moins que ssh, du coup, fournisse un tty virtuel bien localisé).

        Personnellement, pour me connecter d'une machine tout en UTF-8 vers une machine tout en iso-8859, j'utilise "luit" qui sert à traduire ce qui transite d'un encodage vers l'autre, donc sans avoir à toucher à la config ou aux locales:

        [machine en UTF-8]$ LC_ALL=fr_FR luit ssh machine-en-iso-8859

        peut-être que "luit" peut aussi traduire dans l'autre sens ? (je ne peux pas tester là)

        • [^] # Re: variables

          Posté par  . Évalué à 2.

          Tu peux aussi essayer de lancer un xterm, sous la gentoo, en utf8, et de là lancer ton ssh... comme ça les deux bouts se parleront dans la même langue. Dans ce cas il te faut les locales utf8, effectivement:

          $ LC_ALL=fr_CH.UTF-8 xterm -u8

        • [^] # Re: variables

          Posté par  (site web personnel) . Évalué à 1.

          Il est peut etre dit dans un vimrc que l'encodage est utf-8 (ou comme c'est l'encodage par défaut, c'est un comportement sain).
          Pour changer l'encodage a la volee dans vim, faire ":set encoding=iso-8859-1" et ca devrait marcher. Apres, il faut regler le probleme du mais dans quel codage vais-je donc sauver mes fichiers pour que tout ne soit pas completement incoherent apres mon passage.

          --
          Et vive l'utf-32
          Et vive la mondialisation

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.