Bonjour,
j'utilise putty pour me logger en ssh sur un serveur woody.
La version de bash est :
# bash --version
GNU bash, version 2.05a.0(1)-release (i386-pc-linux-gnu)
Copyright 2001 Free Software Foundation, Inc.
J'ai configuré ma locale en UTF-8.
Lorsque je tape la séquence de caractères "ls aé" sur la ligne de
commande, j'ai des caractères "ls aé" qui sont correctement affichés.
Maintenant, je tape backspace pour effacer le "é" et je le remplace
par "2". J'ai les caractères "ls a2" qui sont donc affichés.
Je valide la commande, et bash me retourne une erreur :
# ls a2
ls: aâ??2: Chaîne multi-octets ou étendue de caractères invalide ou
incomplète
Comme vous le voyez, il y a un caractère pourri qui a été inséré,
comme si le caractère codé sur 2 octets n'avait été que
partiellement supprimé.
Je n'ai pas du tout ce comportement sous vim, qui est configuré pour
fonctionner en UTF-8. De même pour putty.
En faisant quelques recherches, j'ai constaté que l'auteur de putty
mettait en garde les utilisateurs sur des incompatibilités possibles
de certaines applications avec unicode.
En cherchant du côté de bash, j'ai trouvé le patch suivant :
ftp://ftp.gnu.org/pub/gnu/bash/bash-2.05b-patches/bash205b-007
Hé ! ça ressemble à un patch pour mon problème.
Le truc, c'est qu'une version 2.05b, il n'y en a pas en paquet,
visiblement.
Par ailleurs, si je regarde le paquet debian 2.05a, c'est une version
patchée, à la debian, j'ai l'impression :
# apt-cache showpkg bash
Package: bash
Versions:
3.0-3(/var/lib/apt/lists/ftp.fr.debian.org_debian_dists_unstable_main_binary-i386_Packages)
2.05a-11(/var/lib/apt/lists/ftp.fr.debian.org_debian_dists_stable_main_binary-i386_Packages)(/var/lib/dpkg/status)
il y a en effet un "-11" qui suit, comme si c'était la 11ème version
du 2.05a pour woody.
Bref, je ne sais pas trop quoi penser : est-ce que le patch 7 pour la
2.05b aurait été appliqué à la 2.05a-11, et que donc le bug existe
toujours ? ou bien faut-il que je compile un bash moi-même ?
Ã?a m'ennuie de devoir compiler le shell sur lequel presque tout le
reste repose, en cas de bug corrigé dans les patches "-11", mais pas
en 2.05b prise sur le site de gnu.
Il y a peut-être un moyen plus simple de corriger le problème, tout
en restant en UTF-8 ? genre virer le mode vi, mais je n'ai pas compris
comment ça marchait.
Je donc suis à l'écoute de vos conseils avisés :)
Bonjour,
j'utilise putty pour me logger en ssh sur un serveur woody.
La version de bash est :
# bash --version
GNU bash, version 2.05a.0(1)-release (i386-pc-linux-gnu)
Copyright 2001 Free Software Foundation, Inc.
J'ai configuré ma locale en UTF-8.
Lorsque je tape la séquence de caractères "ls aé" sur la ligne de
commande, j'ai des caractères "ls aé" qui sont correctement affichés.
Maintenant, je tape backspace pour effacer le "é" et je le remplace
par "2". J'ai les caractères "ls a2" qui sont donc affichés.
Je valide la commande, et bash me retourne une erreur :
# ls a2
ls: aâ??2: Chaîne multi-octets ou étendue de caractères invalide ou
incomplète
Comme vous le voyez, il y a un caractère pourri qui a été inséré,
comme si le caractère codé sur 2 octets n'avait été que
partiellement supprimé.
Je n'ai pas du tout ce comportement sous vim, qui est configuré pour
fonctionner en UTF-8. De même pour putty.
En faisant quelques recherches, j'ai constaté que l'auteur de putty
mettait en garde les utilisateurs sur des incompatibilités possibles
de certaines applications avec unicode.
En cherchant du côté de bash, j'ai trouvé le patch suivant :
ftp://ftp.gnu.org/pub/gnu/bash/bash-2.05b-patches/bash205b-007
Hé ! ça ressemble à un patch pour mon problème.
Le truc, c'est qu'une version 2.05b, il n'y en a pas en paquet,
visiblement.
Par ailleurs, si je regarde le paquet debian 2.05a, c'est une version
patchée, à la debian, j'ai l'impression :
# apt-cache showpkg bash
Package: bash
Versions:
3.0-3(/var/lib/apt/lists/ftp.fr.debian.org_debian_dists_unstable_main_binary-i386_Packages)
2.05a-11(/var/lib/apt/lists/ftp.fr.debian.org_debian_dists_stable_main_binary-i386_Packages)(/var/lib/dpkg/status)
il y a en effet un "-11" qui suit, comme si c'était la 11ème version
du 2.05a pour woody.
Bref, je ne sais pas trop quoi penser : est-ce que le patch 7 pour la
2.05b aurait été appliqué à la 2.05a-11, et que donc le bug existe
toujours ? ou bien faut-il que je compile un bash moi-même ?
Ã?a m'ennuie de devoir compiler le shell sur lequel presque tout le
reste repose, en cas de bug corrigé dans les patches "-11", mais pas
en 2.05b prise sur le site de gnu.
Il y a peut-être un moyen plus simple de corriger le problème, tout
en restant en UTF-8 ? genre virer le mode vi, mais je n'ai pas compris
comment ça marchait.
Je donc suis à l'écoute de vos conseils avisés :)
Bonjour,
j'utilise putty pour me logger en ssh sur un serveur woody.
La version de bash est :
# bash --version
GNU bash, version 2.05a.0(1)-release (i386-pc-linux-gnu)
Copyright 2001 Free Software Foundation, Inc.
J'ai configuré ma locale en UTF-8.
Lorsque je tape la séquence de caractères "ls aé" sur la ligne de
commande, j'ai des caractères "ls aé" qui sont correctement affichés.
Maintenant, je tape backspace pour effacer le "é" et je le remplace
par "2". J'ai les caractères "ls a2" qui sont donc affichés.
Je valide la commande, et bash me retourne une erreur :
# ls a2
ls: aâ??2: Chaîne multi-octets ou étendue de caractères invalide ou
incomplète
Comme vous le voyez, il y a un caractère pourri qui a été inséré,
comme si le caractère codé sur 2 octets n'avait été que
partiellement supprimé.
Je n'ai pas du tout ce comportement sous vim, qui est configuré pour
fonctionner en UTF-8. De même pour putty.
En faisant quelques recherches, j'ai constaté que l'auteur de putty
mettait en garde les utilisateurs sur des incompatibilités possibles
de certaines applications avec unicode.
En cherchant du côté de bash, j'ai trouvé le patch suivant :
ftp://ftp.gnu.org/pub/gnu/bash/bash-2.05b-patches/bash205b-007
Hé ! ça ressemble à un patch pour mon problème.
Le truc, c'est qu'une version 2.05b, il n'y en a pas en paquet,
visiblement.
Par ailleurs, si je regarde le paquet debian 2.05a, c'est une version
patchée, à la debian, j'ai l'impression :
# apt-cache showpkg bash
Package: bash
Versions:
3.0-3(/var/lib/apt/lists/ftp.fr.debian.org_debian_dists_unstable_main_binary-i386_Packages)
2.05a-11(/var/lib/apt/lists/ftp.fr.debian.org_debian_dists_stable_main_binary-i386_Packages)(/var/lib/dpkg/status)
il y a en effet un "-11" qui suit, comme si c'était la 11ème version
du 2.05a pour woody.
Bref, je ne sais pas trop quoi penser : est-ce que le patch 7 pour la
2.05b aurait été appliqué à la 2.05a-11, et que donc le bug existe
toujours ? ou bien faut-il que je compile un bash moi-même ?
Ã?a m'ennuie de devoir compiler le shell sur lequel presque tout le
reste repose, en cas de bug corrigé dans les patches "-11", mais pas
en 2.05b prise sur le site de gnu.
Il y a peut-être un moyen plus simple de corriger le problème, tout
en restant en UTF-8 ? genre virer le mode vi, mais je n'ai pas compris
comment ça marchait.
Je donc suis à l'écoute de vos conseils avisés :)
Bonjour,
j'utilise putty pour me logger en ssh sur un serveur woody.
La version de bash est :
# bash --version
GNU bash, version 2.05a.0(1)-release (i386-pc-linux-gnu)
Copyright 2001 Free Software Foundation, Inc.
J'ai configuré ma locale en UTF-8.
Lorsque je tape la séquence de caractères "ls aé" sur la ligne de
commande, j'ai des caractères "ls aé" qui sont correctement affiché s.
Maintenant, je tape backspace pour effacer le "é" et je le remplace par
"2". J'ai les caractères "ls a2" qui sont donc affichés.
Je valide la commande, et bash me retourne une erreur :
# ls a2
ls: a???2: Chaîne multi-octets ou étendue de caractères invalide ou
incomplète
Comme vous le voyez, il y a un caractère pourri qui a été insér é, comme
Il y a peut-être un moyen plus simple de corriger le problème, tout e n
restant en UTF-8 ? genre virer le mode vi, mais je n'ai pas compris
comment ça marchait.
Je donc suis à l'écoute de vos conseils avisés :)
Bonjour,
j'utilise putty pour me logger en ssh sur un serveur woody.
La version de bash est :
# bash --version
GNU bash, version 2.05a.0(1)-release (i386-pc-linux-gnu)
Copyright 2001 Free Software Foundation, Inc.
J'ai configuré ma locale en UTF-8.
Lorsque je tape la séquence de caractères "ls aé" sur la ligne de
commande, j'ai des caractères "ls aé" qui sont correctement affiché s.
Maintenant, je tape backspace pour effacer le "é" et je le remplace par
"2". J'ai les caractères "ls a2" qui sont donc affichés.
Je valide la commande, et bash me retourne une erreur :
# ls a2
ls: a???2: Chaîne multi-octets ou étendue de caractères invalide ou
incomplète
Comme vous le voyez, il y a un caractère pourri qui a été insér é, comme
Il y a peut-être un moyen plus simple de corriger le problème, tout e n
restant en UTF-8 ? genre virer le mode vi, mais je n'ai pas compris
comment ça marchait.
Je donc suis à l'écoute de vos conseils avisés :)
Bonjour,
j'utilise putty pour me logger en ssh sur un serveur woody.
La version de bash est :
# bash --version
GNU bash, version 2.05a.0(1)-release (i386-pc-linux-gnu)
Copyright 2001 Free Software Foundation, Inc.
J'ai configuré ma locale en UTF-8.
Lorsque je tape la séquence de caractères "ls aé" sur la ligne de
commande, j'ai des caractères "ls aé" qui sont correctement affiché s.
Maintenant, je tape backspace pour effacer le "é" et je le remplace par
"2". J'ai les caractères "ls a2" qui sont donc affichés.
Je valide la commande, et bash me retourne une erreur :
# ls a2
ls: a???2: Chaîne multi-octets ou étendue de caractères invalide ou
incomplète
Comme vous le voyez, il y a un caractère pourri qui a été insér é, comme
Il y a peut-être un moyen plus simple de corriger le problème, tout e n
restant en UTF-8 ? genre virer le mode vi, mais je n'ai pas compris
comment ça marchait.
Je donc suis à l'écoute de vos conseils avisés :)
____ ( '~/.bach_profile' ) __________________________________________ _
/
| export LANG=fr_FR.UTF-8
| export LANGUAGE=fr_FR.UTF-8
| export LC_MESSAGES=fr_FR.UTF-8
| consolechars --font=LarArCyrHeb-16
| unicode_start
_____________________________________________________________________ _
:-)
____ ( '~/.bach_profile' ) __________________________________________ _
/
| export LANG=fr_FR.UTF-8
| export LANGUAGE=fr_FR.UTF-8
| export LC_MESSAGES=fr_FR.UTF-8
| consolechars --font=LarArCyrHeb-16
| unicode_start
_____________________________________________________________________ _
:-)
____ ( '~/.bach_profile' ) __________________________________________ _
/
| export LANG=fr_FR.UTF-8
| export LANGUAGE=fr_FR.UTF-8
| export LC_MESSAGES=fr_FR.UTF-8
| consolechars --font=LarArCyrHeb-16
| unicode_start
_____________________________________________________________________ _
:-)
Bonjour,
>| consolechars --font=LarArCyrHeb-16
>| unicode_start
j'ai l'impression que ces commandes sont destinées pour la console, pas
pour une session distante (via putty par exemple) :
$ consolechars --font=LarArCyrHeb-16
Couldnt get a file descriptor referring to the console
get_console_fd: Argument invalide
$ unicode_start
Couldnt get a file descriptor referring to the console
Couldnt get a file descriptor referring to the console
is_in_UTF8_mode: Ioctl() inappropré pour un périphérique
Already in UTF8 mode
et le message d'erreur d'unicode_start indique bien que je suis déjà en
UTF-8.
Merci de la suggestion, et je retiens le consolechars pour le jour où
j'irai sur la console (j'espère jamais : ça voudrait dire une big pan ne).
Bonjour,
>| consolechars --font=LarArCyrHeb-16
>| unicode_start
j'ai l'impression que ces commandes sont destinées pour la console, pas
pour une session distante (via putty par exemple) :
$ consolechars --font=LarArCyrHeb-16
Couldnt get a file descriptor referring to the console
get_console_fd: Argument invalide
$ unicode_start
Couldnt get a file descriptor referring to the console
Couldnt get a file descriptor referring to the console
is_in_UTF8_mode: Ioctl() inappropré pour un périphérique
Already in UTF8 mode
et le message d'erreur d'unicode_start indique bien que je suis déjà en
UTF-8.
Merci de la suggestion, et je retiens le consolechars pour le jour où
j'irai sur la console (j'espère jamais : ça voudrait dire une big pan ne).
Bonjour,
>| consolechars --font=LarArCyrHeb-16
>| unicode_start
j'ai l'impression que ces commandes sont destinées pour la console, pas
pour une session distante (via putty par exemple) :
$ consolechars --font=LarArCyrHeb-16
Couldnt get a file descriptor referring to the console
get_console_fd: Argument invalide
$ unicode_start
Couldnt get a file descriptor referring to the console
Couldnt get a file descriptor referring to the console
is_in_UTF8_mode: Ioctl() inappropré pour un périphérique
Already in UTF8 mode
et le message d'erreur d'unicode_start indique bien que je suis déjà en
UTF-8.
Merci de la suggestion, et je retiens le consolechars pour le jour où
j'irai sur la console (j'espère jamais : ça voudrait dire une big pan ne).
| consolechars --font=LarArCyrHeb-16
Oops... il est LatArCyrHeb-16
Deja esseyer: /usr/bin/vt-is-UTF8
| consolechars --font=LarArCyrHeb-16
Oops... il est LatArCyrHeb-16
Deja esseyer: /usr/bin/vt-is-UTF8
| consolechars --font=LarArCyrHeb-16
Oops... il est LatArCyrHeb-16
Deja esseyer: /usr/bin/vt-is-UTF8
> J'ai configuré ma locale en UTF-8.
>
C pour ça qu'il y a 1 arbre de noel de caractères bizares, non ?
What about ISO 8859-15 ?
> Je donc suis à l'écoute de vos conseils avisés :)
Voir + haut, si ce n'est pas carrément 1 pb de locales ?
Any other advises ?
> J'ai configuré ma locale en UTF-8.
>
C pour ça qu'il y a 1 arbre de noel de caractères bizares, non ?
What about ISO 8859-15 ?
> Je donc suis à l'écoute de vos conseils avisés :)
Voir + haut, si ce n'est pas carrément 1 pb de locales ?
Any other advises ?
> J'ai configuré ma locale en UTF-8.
>
C pour ça qu'il y a 1 arbre de noel de caractères bizares, non ?
What about ISO 8859-15 ?
> Je donc suis à l'écoute de vos conseils avisés :)
Voir + haut, si ce n'est pas carrément 1 pb de locales ?
Any other advises ?
Bonjour,
peut-être, mais je ne suis toujours pas sur la console, mais avec un
terminal distant, donc, même situation, même punition :
$ consolechars --font=LatArCyrHeb-16
Couldnt get a file descriptor referring to the console
get_console_fd: Argument invalide
La console utilise /dev/console ou /dev/ttyN, et moi je passe par un
/dev/pts . Enfin, c'est la conclusion à laquelle j'arrive, je ne sais
pas si elle est exacte :)
>Deja esseyer: /usr/bin/vt-is-UTF8
$ /usr/bin/vt-is-UTF8
Couldnt get a file descriptor referring to the console
is_in_UTF8_mode: Ioctl() inappropré pour un périphérique
Bonjour,
peut-être, mais je ne suis toujours pas sur la console, mais avec un
terminal distant, donc, même situation, même punition :
$ consolechars --font=LatArCyrHeb-16
Couldnt get a file descriptor referring to the console
get_console_fd: Argument invalide
La console utilise /dev/console ou /dev/ttyN, et moi je passe par un
/dev/pts . Enfin, c'est la conclusion à laquelle j'arrive, je ne sais
pas si elle est exacte :)
>Deja esseyer: /usr/bin/vt-is-UTF8
$ /usr/bin/vt-is-UTF8
Couldnt get a file descriptor referring to the console
is_in_UTF8_mode: Ioctl() inappropré pour un périphérique
Bonjour,
peut-être, mais je ne suis toujours pas sur la console, mais avec un
terminal distant, donc, même situation, même punition :
$ consolechars --font=LatArCyrHeb-16
Couldnt get a file descriptor referring to the console
get_console_fd: Argument invalide
La console utilise /dev/console ou /dev/ttyN, et moi je passe par un
/dev/pts . Enfin, c'est la conclusion à laquelle j'arrive, je ne sais
pas si elle est exacte :)
>Deja esseyer: /usr/bin/vt-is-UTF8
$ /usr/bin/vt-is-UTF8
Couldnt get a file descriptor referring to the console
is_in_UTF8_mode: Ioctl() inappropré pour un périphérique
Bon soir...
ssh mal configure !
Bon soir...
ssh mal configure !
Bon soir...
ssh mal configure !
En regardant le man, je vois une option -t liée au tty. J'essaye
donc un ssh -t, mais j'ai le même comportement. Pour être sûr,
j'essaye un ssh -T, et la, je n'ai plus de terminal (rien n'apparait
sur putty après que j'ai entré mon mot de passe).
Par ailleurs :
«If a 8-bit clean channel is required, one must not request a pty or
should specify no-pty.»
Mais je pense que ça concerne le transfert de données, afin que ces
données ne soient pas interprétées (quand on fait un ssh -c par exemple).
En regardant le man, je vois une option -t liée au tty. J'essaye
donc un ssh -t, mais j'ai le même comportement. Pour être sûr,
j'essaye un ssh -T, et la, je n'ai plus de terminal (rien n'apparait
sur putty après que j'ai entré mon mot de passe).
Par ailleurs :
«If a 8-bit clean channel is required, one must not request a pty or
should specify no-pty.»
Mais je pense que ça concerne le transfert de données, afin que ces
données ne soient pas interprétées (quand on fait un ssh -c par exemple).
En regardant le man, je vois une option -t liée au tty. J'essaye
donc un ssh -t, mais j'ai le même comportement. Pour être sûr,
j'essaye un ssh -T, et la, je n'ai plus de terminal (rien n'apparait
sur putty après que j'ai entré mon mot de passe).
Par ailleurs :
«If a 8-bit clean channel is required, one must not request a pty or
should specify no-pty.»
Mais je pense que ça concerne le transfert de données, afin que ces
données ne soient pas interprétées (quand on fait un ssh -c par exemple).
> Mais je pense que ça concerne le transfert de données, afin que ces
> données ne soient pas interprétées (quand on fait un ssh -c par exemple).
-c c'est une option de chiffrement complètement indépendante. Je
suppose plutôt que c'est pour transférer des fichiers par exemple
(ce que fait scp) ou plus généralement pour installer un tunnel ssh.
> Mais je pense que ça concerne le transfert de données, afin que ces
> données ne soient pas interprétées (quand on fait un ssh -c par exemple).
-c c'est une option de chiffrement complètement indépendante. Je
suppose plutôt que c'est pour transférer des fichiers par exemple
(ce que fait scp) ou plus généralement pour installer un tunnel ssh.
> Mais je pense que ça concerne le transfert de données, afin que ces
> données ne soient pas interprétées (quand on fait un ssh -c par exemple).
-c c'est une option de chiffrement complètement indépendante. Je
suppose plutôt que c'est pour transférer des fichiers par exemple
(ce que fait scp) ou plus généralement pour installer un tunnel ssh.