… Windows.
Ce post récapitule les discussions à l’état où elles sont arrivées sur le thread “Mettre l’accent dans ssh” (Mettre l’accent dans ssh, maintenant fermé).
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 
) 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) 
.
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 dans le thread précédent.