Mettre l'accent dans ssh

[quote=“OlivierMiR”]Je ne comprends toujours pas pourquoi tout le monde me conseille des terminaux (genre rxvt), mais comme ce thread devient un peu long et embrouillé je suggère que nous poursuivions cette discussion sur un nouveau thread : La triste histoire du petit ssh, du grand utf8 et du méchant Windows. Pour putty, MattOTop, qui m’a bien compris, a raison, et je vais essayer sa suggestion. Merci.

Pour clarifier les choses, je vous propose de ne plus poster dans ce thread si vous voulez bien.[/quote]Bon, ici, ce n’est pas la pratique de multiplier les fils: un sujet, un fil, et quand c’est résolu, on modifie le titre du premier titre, avec la mention [résolu].
Même si le fil dérive, on s’accroche.
Mais bon.
En ce qui me concerne, je parlais de xterm surtout pour BTB, parceque pour une solution légère, il ne te suffit peut être que d’openssh et des libs cygwin pour tourner comme tu souhaites.
Simplement, si tu veux tester, il te faut une console utf8, donc un xterm+xwindows sous cygwin.

[quote=“MattOTop”]
Bon, ici, ce n’est pas la pratique de multiplier les fils: un sujet, un fil, et quand c’est résolu, on modifie le titre du premier titre, avec la mention [résolu].
Même si le fil dérive, on s’accroche.[/quote]

Ok, désolé, je ne savais pas que ça ne se faisait pas ici. J’ai voulu bien faire :confused:.

Je vais donc re-poster mon post “divergeant” dans ce thread-ci. Puisque tu es modérateur, tu peux peut-être fermer l’autre (le nouveau) pour réparer mes bêtises ?

[quote]
En ce qui me concerne, je parlais de xterm surtout pour BTB, parceque pour une solution légère, il ne te suffit peut être que d’openssh et des libs cygwin pour tourner comme tu souhaites.
Simplement, si tu veux tester, il te faut une console utf8, donc un xterm+xwindows sous cygwin.[/quote]
Oui, pour ta remarque j’avais compris, pas de problème (sauf que c’est quoi BTB ?).

Je ferais plus tard la suppression, alors, si tu veux.

… Windows.

Bon, récapitulons…

La demande

Un client ssh sous Windows avec une interface en ligne de commande compatible Linux (doit comprendre l’option -e par exemple), et supportant les noms de fichiers encodés en utf8 sur la machine de destination.

Précision du contexte

Unison, le programme que j’essaie d’utiliser sur ma machine Windows, fait appel à ssh. Il me faut donc un client ssh sous Windows qui sont “compatible LINUX”, ou en tous cas, compatible avec ce que Unison attend de lui. C’est-à-dire qu’il faut par exemple, pouvoir appeler ssh avec l’option -e à la ligne de commande.

Je cherche la solution la plus légère possible (pas envie d’installer des tas de trucs juste pour un client ssh que je n’utiliserai pas à part pour Unison).

Tentatives de solutions

Terminaux

Plusieurs terminaux (Gnome-Terminal ; Konsole ; xterm ; uxterm ; rxvt ; tous via Cygwin) supportant utf8 m’ont été proposés, mais je ne comprends pas bien pourquoi : il me semble qu’il me faut plutôt un client ssh.

Clients ssh

Les clients suivants ont été essayés :

[ul][li] putty : pas de support de l’option -e[/li]
[li] plink : pas de support de l’option -e, de plus semble ne pas supporter l’utf8, et problème avec la touche backslash. BorisTheButcher propose quelque chose avec Ctrl+H mais je ne sais pas à quoi cela répond, et ça ne résoud pas le premier problème (pas de support de l’option -e).[/li]
[li] ssh 1.2.14 : pas de support de utf8[/li]
[li] Tera Term Pro : pas de support utf8[/li]
[li] cygwin & openssh : pas encore testé. MattOTop (qui m’a bien compris, merci pour sa lecture attentive :smiley:) indique que pour tester avant, il faut un xterm, qui sur sa Debian supporte effectivement l’utf8.[/li][/ul]Scripting autour de putty

Une idée audacieuse serait de créer un ssh.bat, de faire en sorte qu’Unison l’appelle, et dans le .bat d’appeler putty. Seulement :
[ul][li]il n’est pas certain que ça résoudrait le problème, car l’option -e n’ayant pas d’équivalent avec putty, il faudrait simplement que je la néglige, et Unison pourrait être fâché[/li]
[li] ca prendrait plein de temps de comprendre comment Unison fonctionne et d’arriver à quelque chose qui marche[/li]
[li] j’ai quand même essayé de le faire mais, premier problème : Unison me dit Uncaught exception Unix.Unix_error(20, "create_process", "ssh"), autrement dit il essaye de créer un process ssh, qu’il ne voit pas quand je fais un ssh.bat ou ssh.cmd. Je pense qu’il cherche un .exe.[/li]
[li] le seul compilateur bat vers EXE ou COM gratuit semble être BAT2EXEC (voir par exemple http://forum.hardware.fr/hardwarefr/Programmation/Compiler-fichier-batch-sujet-68158-1.htm). Il faut renommer la sortie de SSH.COM en ssh.exe, sinon Unison crashe de la même façon. Mais l’expérience s’arrête là : mon ssh.bat contient echo %* > out.txt, ce qui marche très bien avant compilation. Après compilation, taper ssh.exe coucou crée un fichier out.txt illisible (c-à-d dont le contenu ne resssemble pas à de l’ASCII).[/li][/ul]Autres

BorisTheButcher propose, comme solution plus sage, de virer Windows. Ce que je vais considérer (mais pas maintenant) :wink:.

Interrogation

Je me demande si le problème vient réellement du client ssh qui ne supporterait pas l’utf8, néanmoins, ou si j’ai un problème avec mon terminal ou mon environnement Linux ou je ne sais quoi : quand je lance ssh depuis ma machine Windows (ssh 1.2.14), me logge sous Linux, je vois les caractères accentués bizarrement. Jusque là, on le savait déjà. Mais par contre si je tape “bash”, puis ls, là c’est TOUS les caractères qui apparaissent très bizarrement, pas seulement les quelques accents remplacés par d’autres caractères. Ensuite je tape exit et retape ls : comme au début, seuls les accents sont bizarres. Si je tape vim, même chose : tous des caractères super bizarres. Après “:q” et retour à l’invite de commande linux, de nouvau comme au début (seulement les accents ne passent pas).

Une idée ? Pensez-vous vraiment que c’est juste le client ssh qui pose problème ? (En attendant je vais essayer avec cygwin + openssh quand j’aurai le temps.)

Merci en tous cas encore une fois aux répondants…

Salut

Le ssh que t’as essayé si il supporte pas l’utf8, laisse tomber.

Si je ne me trompe pas, une session ssh (une vraie sur un OS digne de ce nom) se passe comme ca:

En local, tu lance ton serveur X. Ce dernier utilise XFontServer qui doit avoir en stock une fonte avec l’encodage correct ( ex -misc-fixed-medium-r-normal–8-80-75-75-c-50-iso10646-1 )
Tu lances ton terminal X (donc en fonte susnommée) avec dedans bash, qui lui a comme locale UTF-8. Ca defninit quelle “langue tu parle”.
Tu lance ton client texte ssh.
Ca se connecte au serveur ssh qui lance le shell de l’utilisateur (/etc/passwd), ex bash qui lui va lancer son fichier d’initialisation (man bash , /etc/profile, /etc/bashrc, ~/.bashrc un truc comme ca). Cette init fixe aussi la locale à UTF8.
Tu tappes un
ls コンニチハ.txt ca s’affiche grace à ta fonte (au niveau du clavier c’est plus dur :laughing:)
Ca part en utf8 sul’ fil.
Ca arrive au serveur ssh puis bash distant qui est en locale UTF8 donc il comprend cette commande et aussi renvoie le resultat en utf8.

Donc en local si tu veux afficher il te faut un système d’affichage qui gère l’utf8. Pas celui de windows (gdi et ses fontes truetype).
Soit tu prends une appli graphique toute faite (comme ton ssh que t’as trouvé) qui redessine les fontes UTF8 à la volée (… hum pas evident) sans se baser sur les fontes de windows.
Soit tu prend un autre système d’affichage : cygwin avec Xwindow+fonte+Xterm+clientssh

Si tu n’as pas besoin d’un client ssh qui s’affiche (ex ton appli prend la sortie du client ssh et l’affiche elle meme) alors il faut absolument que ton appli gère l’utf8 et le client ssh local n’a pas grand chose à faire.

Oula en me relisant c’est pas si clair :slightly_smiling:
J’espere que j’ai pas dit trop d’anneries.
Bon courage.

[quote=“BorisTheButcher”]Le ssh que t’as essayé si il supporte pas l’utf8, laisse tomber.

Si tu n’as pas besoin d’un client ssh qui s’affiche (ex ton appli prend la sortie du client ssh et l’affiche elle meme) alors il faut absolument que ton appli gère l’utf8 et le client ssh local n’a pas grand chose à faire.

Oula en me relisant c’est pas si clair :slightly_smiling:
J’espere que j’ai pas dit trop d’anneries.
Bon courage.[/quote]
Mmh ça s’éclaircit progressivement. Je crois comprendre que finalement le client ssh n’importe pas : c’est Unison qui contrôle ssh, qui lui passe les commandes et récupère le résultat. Donc je suppose que c’est Unison qui ne supporte pas l’utf8… Ce qui voudrait dire que je suis parti dans une mauvaise direction depuis le début !

Et mes essais avec différents clients ssh ne sont pas très informatifs car finalement ce n’est pas le client ssh qui compte mais le terminal dans lequel il affiche les résultats… Lorsque c’est le terminal “invite de commande” de Windows, forcément, ça ne fonctionne pas, vu que le terminal ne gère pas l’utf8 (je pense)…

Vrai ?

Si quelqu’un comprend l’allemand (moi pas), ce sujet peut être intéressant.

Ceci par contre est plutôt déprimant : Unison ne supporte pas l’utf8 (juin 2004) ; et Unison gère mal les accents (mars 2006).

La discussion devient plus spécifique à Unison, et je devrais peut-être plutôt m’adresser à un forum plus spécifique, mais comme il a l’air d’y avoir des gens pas cons par ici, je demande à tout hasard : quelqu’un aurait une idée pour contourner le problème… Peut-être du genre switch pour demander à linux d’afficher es noms de fichiers en un format “compatible Windows” momentanément (juste le temps que je synchronise avec Unison) ou autre solution inventive ?

Ou carrément un autre programme pour synchroniser Windows - Linux ?

Bon, hier, 5mn après avoir posté je me suis rendu compte que j’avais dit une connerie encore :slightly_smiling:
Je suis vraimment désolé…
Ca marche pas exactement comme ca.

[code]ssh -vvv user@serveur:

debug1: Sending environment.
debug3: Ignored env KDE_MULTIHEAD
debug3: Ignored env SSH_AGENT_PID
debug3: Ignored env DM_CONTROL
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env DESKTOP_STARTUP_ID
debug3: Ignored env XDM_MANAGED
debug3: Ignored env GTK2_RC_FILES
debug3: Ignored env CVSROOT
debug3: Ignored env GTK_RC_FILES
debug3: Ignored env GS_LIB
debug3: Ignored env WINDOWID
debug3: Ignored env KDE_FULL_SESSION
debug3: Ignored env http_proxy
debug3: Ignored env XTERM_SHELL
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env ftp_proxy
debug3: Ignored env SESSION_MANAGER
debug3: Ignored env XPSERVERLIST
debug3: Ignored env PATH
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env PWD
debug1: Sending env LANG = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env XUSERFILESEARCHPATH
debug3: Ignored env XTERM_VERSION
debug3: Ignored env HOME
debug3: Ignored env SHLVL
debug3: Ignored env LANGUAGE
debug3: Ignored env GREP_OPTIONS
debug3: Ignored env XCURSOR_THEME
debug3: Ignored env LOGNAME
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env DISPLAY
debug3: Ignored env _
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 16384
debug2: channel 0: rcvd adjust 32768[/code]

Ca parait presque logique, pourquoi faire parler un client ssh en utf8 avec un serveur ssh en 8859-1 ou autre, ca ne sert à rien.

Donc en fait, le client ssh envoie l’environnement courant (contenant la locale LANG) au serveur ssh qui l’envoie a son bash. Il ya donc une phase d’etablissement de connexion.

Mais j’y pense, t’es vraimment obligé d’utiliser utf8? Parceque 8859-1 ou 8859-15 gère les accents, c’est des extensions ASCII et y a des chances que unison les affiche.

[quote=“BorisTheButcher”]
Ca parait presque logique, pourquoi faire parler un client ssh en utf8 avec un serveur ssh en 8859-1 ou autre, ca ne sert à rien.

Donc en fait, le client ssh envoie l’environnement courant (contenant la locale LANG) au serveur ssh qui l’envoie a son bash. Il ya donc une phase d’etablissement de connexion.[/quote]Heuuu je ne comprends pas en quoi ça contredit ou modifie ma compréhension et ma conclusion précédente ? Veux-tu dire que je fais fausse route ?

[quote=“BorisTheButcher”]Mais j’y pense, t’es vraimment obligé d’utiliser utf8? Parceque 8859-1 ou 8859-15 gère les accents, c’est des extensions ASCII et y a des chances que unison les affiche.[/quote]Vraiment obligé, non. J’ai fait ce choix car ça me semblait être plus international et pour des raisons de compatibilté dans Samba. Je ne sais plus très bien quel était le raisonnement à la base, mais peu importe à la limite : je crains que re-changer maintenant simplement parce que je ne m’en sors pas avec Unison me prenne beaucoup de temps et ne fasse que déplacer le problème, en rendant d’autres applications incompatibles (raison pour laquelle je suis passé en utf8 au départ). Du reste, je suppose que viendra un jour où tout le monde sera en utf8, non ? J’ai l’impression que c’est plutôt à Unison de supporter l’utf8 (où à moi de trouver un moyen ou une application qui le supporte) plutôt que de choisir un codage moins complet ou moins international…

Sans compter que ce serait abdiquer et donner victoire à mon ordinateur, et ça me ferait mal :slightly_smiling:.