Mettre l'accent dans ssh

Bonjour,

Sur ma machine Linux (Debian), les noms de fichiers sont encodés en UTF-8. Quand j’ouvre un terminal dessus, pas de problème : ls rend correctement les caractères accentués. Y compris si je fais un ssh depuis ma propre machine (même via ssh sur une tierce machine). Par contre, si je fais un ssh depuis ma machine Windows, ls donne des caractères bizarres. La commande “echo -n é | wc -c” répond 1, ce qui semble indiquer qu’effectivement le terminal n’est pas en UTF-8 (car en UTF-8 é est codé sur 2 caractères).

Que devrais-je vérifier ? Est-ce dû au programme ssh que j’utilise ? Au terminal de Windows ? Le terminal lancé par ssh n’est-il pas mon bash habituel ?

Merci pour toute aide !

Je dirai que c’est du au client ssh qui ne comprend pas l’utf8.
Faut que t’en prenne un autre, peut etre depuis cygwin?

edit:putty semble gerer l’utf8

Gnome-Terminal ou Konsole te permet de choisir l’encodage.
Même avec plusieurs onglets, tu pourras choisir par onglet l’encodage voulu.

Putty aussi permet de choisir l’encodage aussi, a faire avant la connexion.

[quote=“gwadboy”]Konsole te permet de choisir l’encodage.
[/quote]
T’as essayé en utf8? (je suis curieux car chez moi c’est pas concluant…)

Ni gnome ni kde sont necessaire.

UXTERM rocks

Si Konsole est installer ben pas besoin d’installer UXTERM.

:confused:

Pour Konsole.

Configuration --> Encodage : --> utf8, iso 8859-15 etc…

Au cas ou tu utilise Konsole ou Gnome-Terminal ben c’est possible.

8)

Oui chez moi avec Konsole utf8 fonctionne.

[quote=“gwadboy”]Si Konsole est installer ben pas besoin d’installer UXTERM.

:confused:
[/quote]
:laughing:
Si j’ai besoin d’un terminal X, qui marche, rapide, qui tire pas 48 librairies, qui ne reinvente pas la roue et qui suit les standards XWindow, je prend xterm.

[quote]
Pour Konsole.

Configuration --> Encodage : --> uth8, iso 8859-15 etc…

Au cas ou tu utilise Konsole […] ben c’est possible.

8)[/quote]
Je repete
As-tu essayé sur un fichier utf8?

Comme fichier utf8 prends voir cuila:
cl.cam.ac.uk/~mgk25/ucs/exam … 8-demo.txt

Ensuite fait un cat dessus suivi d’un 'ti pageup.

Si ca marche à peu près j’ai rien dit.

Arrètez de troller: le problême est depuis une machine windows, et sous cygwin, on a pas le choix, me semble t il, et c’est xterm par défaut (ou la console cygwin, mais vraiment beurk, c’est une fenètre windows).

[quote=“MattOTop”]Arrètez de troller: le problême est depuis une machine windows
[/quote]
Ah non je trolle pas, j’apporte des faits concrets. Il en reste un que je veux verifier… vu que j’ai tendance à traffiquer ma machine, je veux savoir si c’est que chez moi (ds ce cas je l’ouvre plus pour konsole promis :laughing:)

[quote]
et sous cygwin, on a pas le choix, me semble t il, et c’est xterm par défaut (ou la console cygwin, mais vraiment beurk, c’est une fenètre windows).[/quote]
Je crois que cygwin n’est pas à jour sur l’utf8; c’est des vielles versions.
C’est pourquoi je recommandais putty, cf mon 1er post.

Oui, mais putty est payant, normalement, me semble t il.
:wink:

:wink:

[quote=“MattOTop”]Oui, mais putty est payant, normalement, me semble t il.
:wink:[/quote]

Gratos , en licence MIT

Je ne vois pas d’autre solution… peut etre tera term pro mais putty est quand meme plus clean.

Bonojur,

Merci à tous pour cette avalanche de réponse. Je n’en espérais pas tant !

Précision du contexte

Unison, le programme que j’essaie d’utiliser, 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. putty fournit un putty.exe qui, même renommé en ssh.exe, n’est pas satisfaisant puisqu’il ne comprend pas l’option -e.

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, vu que j’ai l’habitude d’utiliser Putty).

Comprend pas

J’ai une question technique par rapport à votre idée que le problème vient du client ssh que j’utilise - ce qui semble se confirmer, vu qu’effectivement avec putty mes caractères accentués s’affichent correctement alors qu’avec ssh 1.2.14 (http://sourceforge.net/project/showfiles.php?group_id=7355) non. Je ne comprend pas comment cela est possible, puisque selon moi ssh n’est pas un terminal mais uniquement un protocole pour communiquer de façon sûre, sachant que ce que ssh utilise en fait est mon bash habituel sur mon Linux habituel… Il ne fait que chiffrer les communications dema machine Linux à ma machine Windows, non ? Et ne devrait donc pas être perturbé par des caractères UTF-8 ou quoi que ce soit…

Solution

Quoi qu’il en soit de mon incompréhension, je vois donc que la solution la plus légère qui m’est proposée est d’installer cygwin et uxterm ? Ou cygwin et xterm, dit un des posts, mais je pensais avoir compris que uxterm est xterm avec le support Unicode (justement ce que j’ai besoin)… Je suis un peu perdu… (Quoique déjà moins qu’avant ;- ).)

Pas d’idée d’un client ssh natif windows (qui me permettrait de me passer de cygwin) ? Eclipse par exemple fait usage de ssh, sur Windows comme sur Linux, donc je suppose qu’il doit bien exister des clients ssh modernes (i.e., supportant UTF8, pas comme ssh 1.2.14) et cross-platform (i.e., compatible avec l’interface en ligne de commande Linux, pas comme putty)…

Merci encore pour votre aide !

Tera Term Pro ne semble pas convenir non plus : pas de support UTF-8. Et il ne semble pas évident de l’utiliser en ligne de commande (bien que je n’aie pas beaucoup cherché)…

Je doute que cygwin resolve tes problèmes, je pense que c’est trop vieux.

As-tu essayé plink de putty? Je sais pas si il gère le -e mais avec un ssh.exe contenant du script batch ca devrait passer non?

[quote]
Il ne fait que chiffrer les communications dema machine Linux à ma machine Windows, non [/quote]
Oui mais ce qui transite c’est de “l’utf8 sur tcp/ip”. Si les 2 n’utilisent pas le meme protocole de discussion (encodage de caractères) ben t’as des trucs bizarres.

[quote=“BorisTheButcher”]Je doute que cygwin resolve tes problèmes, je pense que c’est trop vieux.[/quote]Ah… Cela signifie que tu ne vois pas de solution à mon problème ? Je ne comprends pas ce que signifie “trop vieux” : cygwin est un environnement qui permet d’installer toutes sortes de programmes tournant sous linux, non ? Quel que soit leur âge… Donc je pourrais très bien l’utiliser pour installer un ssh récent supportant unicode, non ?

D’ailleurs à ce propos j’ai été idiot dans ma réponse précédente : ce qu’il me faut, si je comprends bien, est bien un autre client ssh (éventuellement sous cygwin ou autre), comme tu proposais en première réponse, et non un autre terminal du type xterm…

[quote=“BorisTheButcher”]As-tu essayé plink de putty? Je sais pas si il gère le -e mais avec un ssh.exe contenant du script batch ca devrait passer non?[/quote]plink fonctionne différement de putty : plink ne lance pas un nouveau terminal, il fonctionne dans le terminal de Windows. Je pense que c’est pourquoi il ne semble pas supporter l’utf8 non plus (même problème de visibilité des caractères accentués). (De plus il pose un étrange problème : quand j’utilise backspace après login sur ma machine Linux depuis plink sur ma machine Windows, au lieu de revenir en arrière, il affiche un caractère bizarre… Mais de toute façonceci ne concerne pas directement mon problème initial.)

Donc j’avais plutôt essayé de copier putty.exe en le renommant en ssh.exe. Effectivement, au lieu de cela, je pourrais faire un batch “ssh.exe” qui appelle à son tour putty mais en transformant la ligne de commande. Ceci nécessiterait, outre de trouver un compilateur en exe d’un batch, que je passe beaucoup de temps à comprendre comment Unicode appelle ssh pour parser correctement la ligne de commande… Sans garantie que j’y arrive à la fin. Dans le même ordre d’idée, je pourrais aussi patcher Unicode pour changer la façon dont il appelle ssh.

C’est beaucoup trop de temps à investir par rapport au but cherché (simplement utiliser un outil pratique pour synchroniser ma machine Linux et Windows).

[quote=“BorisTheButcher”]
Oui mais ce qui transite c’est de “l’utf8 sur tcp/ip”. Si les 2 n’utilisent pas le meme protocole de discussion (encodage de caractères) ben t’as des trucs bizarres.[/quote]Ok, compris.

[quote=“OlivierMiR”][quote=“BorisTheButcher”]Je doute que cygwin resolve tes problèmes, je pense que c’est trop vieux.[/quote]Ah… Cela signifie que tu ne vois pas de solution à mon problème ? Je ne comprends pas ce que signifie “trop vieux” : cygwin est un environnement qui permet d’installer toutes sortes de programmes tournant sous linux, non ? Quel que soit leur âge… Donc je pourrais très bien l’utiliser pour installer un ssh récent supportant unicode, non ?
[/quote]
Euh je crois que j’ai dit une connerie en fait, j’ai confondu avec Xwindow.
Alors reprenons :slightly_smiling:
Solution 1)
Tu prends cygwin et tu prends rxvt qui est dans /usr/bin. Il se base sur la gdi de windows et prends une fonte bilou. Bilou gère -t-il l’utf8 d’après vous? (je vous laisse repondre)
Donc j’ai peur que ca marche pas…

Solution 2)
Tu prends cygwin et Xwindow (ca commence à faire…) puis le rxvt (par exemple) de /usr/X11/bin. Et tu prends une bonne police avec l’encodage iso10646:
-misc-fixed-medium-r-semicondensed–13-120-75-75-c-60-iso10646-1
rxvt -fn -misc-fixed-medium-r-semicondensed–13-120-75-75-c-60-iso10646-1
Faut peut etre installer ces polices

Soit un client ssh graphique pur windows (putty en AYANT BIEN MODIFIé dans le menu l’encodage sinon ca marchera pas…)
Soit un client ssh linux (donc ligne de commande) qui va etre lancé dans un terminal supportant l’utf8 et donc avec une police suportant l’utf8.

Peut-etre avec Ctrl-H car ton terminal doit pas etre bien configuré. Il y a des milliers de site sur ce problème.

Solution 3
Putty
Plink
La plus rapide

Solution 4
Virer windows
La plus sage

Cygwin me semble donc la solution.
Si tu installes juste openssh, tu ne verras pas qu’il fonctionne en utf8, mais le ssh AMA te fournira les fonctionnalités d’utf8 dont tu as besoin.
Si tu souhaites tester avant, il faut effectivement sélectionner un xterm, qui, chez moi en tout cas sous debian, supporte l’utf8, et tu devrais pouvoir te connecter en terminal utf8 pour tester tes commandes.

[quote=“MattOTop”]Cygwin me semble donc la solution.
[/quote]
Pourquoi pas putty?
J’ai ptet loupé un wagon sur le besoin initial…
Parceque c’est cygwin ET Xwindow qu’il faut.

Ah sans l’afficher? Ah oui j’ai relu le thread, c’est pour lancer une commande…

[quote]
Si tu souhaites tester avant, il faut effectivement sélectionner un xterm, qui, chez moi en tout cas sous debian, supporte l’utf8, et tu devrais pouvoir te connecter en terminal utf8 pour tester tes commandes.[/quote]
xterm… xterm… le vrai xterm ? Nan parceque ca m’interesse :wink: Vu que la seule réponse que j’ai eu precedemment était un smilley.

Je vais faire une these sur l’utf8 je crois :laughing:

pas putty parceque si j’ai bien compris OlivierMiR, il lui faut l’option pour fixer le shell escape (-e) d’openssh pour lancer sa connection, et que même en scriptant, de toutes les manières, putty ne le fournit pas.
L’openssh de cygwin, si.
Pour ce qui est du xterm de cygwin*, je n’ai pas testé (il faudrait que j’allume une machine windows), mais celui de ma debian, quand je fais un clic gauche, non, droit, non, central, je sais plus avec xterm, ben je vois apparaitre une option utf8 (les autres sont grisées, d’ailleurs).
Enfin ce que j’en dis: je ne comprends pas la complexité de mise en oeuvre de l’utf8, et comme je ne m’en sers pas…
*Edit: qui est le term par défaut quand on install x, sous cygwin, et la console par défaut lancée par startxwin.bat quand on est sans wm.

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.