je fait un nouveau fil pour repartir à 0 avec les infos que j'ai eues
depuis la dernière fois, et peut être toucher plus de monde
(en espérant être assez clair cette fois ci)
j'ai mac os x 10.6.5
j'ai un gros pb avec mon terminal
comme je ne sais pas le décrire en peu de mots, je vais vous dérouler le
protocole pour le reproduire :
- cherchez n'importe quel fichier ou dossier sur le disque avec un
accent dans son nom (attention : les dossiers du dossier de départ n'en
ont pas)
- glissez le dans le terminal
- avec la flèche vers le haut et la flèche vers le bas, on fait
plusieurs fois le va et vient entre cette ligne et juste la dernière
ligne de l'historique, pas besoin d'aller plus loin
si vous avez le même pb que moi,
même si le nom du fichier avec un accent tient sur 1 seule ligne, ça
doit manger un caractère à chaque passage, normalement
(et si ça s'étend sur plusieurs lignes, ça mange des lignes aussi)
voilà, est ce que ceux qui veulent bien essayer réussissent à reproduire
mon pb ?
il semblerait que certains réussissent à reproduire mon pb, mais pas
tous,
alors ce que j'aimerais, si tout le monde veut bien,
c'est trouver ce qu'il y a comme différences, entre les ordis qui ont le
pb et les ordis qui ne l'ont pas :-)
Puisque ici ça marche correctement, oui (pour information j'ai testé bash-4.2.7 avec readline-6.2.000).
$ otool -L /opt/local/bin/bash /opt/local/bin/bash: [...] /opt/local/lib/libreadline.6.2.dylib (compatibility version 6.0.0, current version 6.2.0) [...]
c'est juste ce qu'il faut pour m'apprendre à chercher :-)
Tu pousses un peu loin, les pages man cela fait maintenant 10 ans qu'on en parle sur fcomox.
mais pas dans mac os x si ça a été corrigé dans le monde libre, il fallait faire ce signalement pour que ça soit intégré à mac os x dans les formes
Soit mais le premier patch corrigeant en partie ce bug fut soumis par un développeur de chez Apple; on peut donc se douter qu'ils soient au courant mais que mettre à jour le vieux bash inclus avec Mac OS X 10.6 ne soit pas une priorité...
mais ce qui m'interloque le plus, là tout de suite, c'est que j'ai tjr le pb avec la version de macports
Tu as peut-être ton émulateur de terminal qui n'utilise pas un encodage adéquat ou bien un vieux ~/.(ba)sh_history
Ici, je le rappelle ça fonctionne comme convenu avec un bash et un readline installés avec MacPorts et un environnement par défaut (mes fichiers rc et profile ne sont exécutés que si le shell est un zsh-4.x)
je suis pas sur d'être censé faire qqch avec ces patchs ou pas, non, ils sont censés être intégrés à la version de macports qui est censée marcher, c'est ça ?
Ces patchs ont été intégrés à la branche 3.2 de bash et sont donc ipso facto inclus dans la branche 4.x
donc j'ai pas besoin de moi même en faire qqch ?
Oui. J'ai collé ces liens pour te montrer que le bug dont tu parlais était corrigé depuis belle lurette.
-- echo '' | tr '[a-z]' '[n-za-m]'
On Jeu 05 mai 2011, 13:27,
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
est ce que la version de readline est bonne ?
Puisque ici ça marche correctement, oui (pour information j'ai testé
bash-4.2.7 avec readline-6.2.000).
$ otool -L /opt/local/bin/bash
/opt/local/bin/bash:
[...]
/opt/local/lib/libreadline.6.2.dylib (compatibility version 6.0.0,
current version 6.2.0)
[...]
c'est juste ce qu'il faut pour m'apprendre à chercher :-)
Tu pousses un peu loin, les pages man cela fait maintenant 10 ans qu'on
en parle sur fcomox.
mais pas dans mac os x
si ça a été corrigé dans le monde libre, il fallait faire ce signalement
pour que ça soit intégré à mac os x dans les formes
Soit mais le premier patch corrigeant en partie ce bug fut soumis par un
développeur de chez Apple; on peut donc se douter qu'ils soient au
courant mais que mettre à jour le vieux bash inclus avec Mac OS X 10.6
ne soit pas une priorité...
mais ce qui m'interloque le plus, là tout de suite, c'est que j'ai tjr
le pb avec la version de macports
Tu as peut-être ton émulateur de terminal qui n'utilise pas un encodage
adéquat ou bien un vieux ~/.(ba)sh_history
Ici, je le rappelle ça fonctionne comme convenu avec un bash et un
readline installés avec MacPorts et un environnement par défaut (mes
fichiers rc et profile ne sont exécutés que si le shell est un zsh-4.x)
je suis pas sur d'être censé faire qqch avec ces patchs ou pas,
non, ils sont censés être intégrés à la version de macports qui est
censée marcher, c'est ça ?
Ces patchs ont été intégrés à la branche 3.2 de bash et sont donc ipso
facto inclus dans la branche 4.x
donc j'ai pas besoin de moi même en faire qqch ?
Oui. J'ai collé ces liens pour te montrer que le bug dont tu parlais
était corrigé depuis belle lurette.
Puisque ici ça marche correctement, oui (pour information j'ai testé bash-4.2.7 avec readline-6.2.000).
$ otool -L /opt/local/bin/bash /opt/local/bin/bash: [...] /opt/local/lib/libreadline.6.2.dylib (compatibility version 6.0.0, current version 6.2.0) [...]
c'est juste ce qu'il faut pour m'apprendre à chercher :-)
Tu pousses un peu loin, les pages man cela fait maintenant 10 ans qu'on en parle sur fcomox.
mais pas dans mac os x si ça a été corrigé dans le monde libre, il fallait faire ce signalement pour que ça soit intégré à mac os x dans les formes
Soit mais le premier patch corrigeant en partie ce bug fut soumis par un développeur de chez Apple; on peut donc se douter qu'ils soient au courant mais que mettre à jour le vieux bash inclus avec Mac OS X 10.6 ne soit pas une priorité...
mais ce qui m'interloque le plus, là tout de suite, c'est que j'ai tjr le pb avec la version de macports
Tu as peut-être ton émulateur de terminal qui n'utilise pas un encodage adéquat ou bien un vieux ~/.(ba)sh_history
Ici, je le rappelle ça fonctionne comme convenu avec un bash et un readline installés avec MacPorts et un environnement par défaut (mes fichiers rc et profile ne sont exécutés que si le shell est un zsh-4.x)
je suis pas sur d'être censé faire qqch avec ces patchs ou pas, non, ils sont censés être intégrés à la version de macports qui est censée marcher, c'est ça ?
Ces patchs ont été intégrés à la branche 3.2 de bash et sont donc ipso facto inclus dans la branche 4.x
donc j'ai pas besoin de moi même en faire qqch ?
Oui. J'ai collé ces liens pour te montrer que le bug dont tu parlais était corrigé depuis belle lurette.
-- echo '' | tr '[a-z]' '[n-za-m]'
Thomas
In article <imb2el$1vd6$, Matt wrote:
On Mar 22 mar 2011, 04:38, Thomas wrote:
> bonjour :-)
Hello le rieur,
> voilà, est ce que ceux qui veulent bien essayer réussissent à reproduire > mon pb ?
> il semblerait que certains réussissent à reproduire mon pb, mais pas > tous, > alors ce que j'aimerais, si tout le monde veut bien, > c'est trouver ce qu'il y a comme différences, entre les ordis qui ont le > pb et les ordis qui ne l'ont pas :-)
Cela provient d'un bug de la version de readline (5.1 - 2005 !) utilisée lors de la compilation de bash livré par défaut avec Mac OS X 10.6; qui on peut le dire, est relativement vieillotte (3.2.48 - novembre 2008).
Avec la dernière version de bash et celle de readline, le comportement est correct.
bon alors, je reprend ce msg ci, parce que voilà ce que j'ai trouvé :
apparemment, la version 3.2.48 a ce bug corrigé (en tout cas autant que la version 4)
par contre, ce bug resurgit si on exécute PS1="&# $PS1" (peu importe que ça soit via le profile ou directement en interactif)
ce qui explique que certains n'arrivaient pas à reproduire le pb !
sais tu comment ça se fait ?
et il y a un autre pb : c'est qu'apparemment, ce petit bug qui a été (en partie) corrigé, il était à l'intérieur d'un plus gros bug qui ne l'a pas été :
si t'as tjr un fichier dont le nom contient un accent, - commences par appuyer plusieurs fois sur entrée, de manière à faire plusieurs lignes - glisses le fichier autant de fois que nécessaire pour dépasser la largeur du terminal - ensuite, au choix, joues avec l'historique comme la dernière fois, ou redimentionnes la fenêtre, dans les 2 sens
ça devrais te faire un beau bazar :-P
tiens moi au courant si t'as à nouveau besoin que je te fasse des copies d'écran
In article <imb2el$1vd6$2@talisker.lacave.net>,
Matt <hfrarg@syrius.org.invalid> wrote:
On Mar 22 mar 2011, 04:38,
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> bonjour :-)
Hello le rieur,
> voilà, est ce que ceux qui veulent bien essayer réussissent à reproduire
> mon pb ?
> il semblerait que certains réussissent à reproduire mon pb, mais pas
> tous,
> alors ce que j'aimerais, si tout le monde veut bien,
> c'est trouver ce qu'il y a comme différences, entre les ordis qui ont le
> pb et les ordis qui ne l'ont pas :-)
Cela provient d'un bug de la version de readline (5.1 - 2005 !)
utilisée lors de la compilation de bash livré par défaut avec Mac OS X
10.6; qui on peut le dire, est relativement vieillotte (3.2.48 -
novembre 2008).
Avec la dernière version de bash et celle de readline, le comportement
est correct.
bon alors, je reprend ce msg ci, parce que voilà ce que j'ai trouvé :
apparemment, la version 3.2.48 a ce bug corrigé (en tout cas autant que
la version 4)
par contre, ce bug resurgit si on exécute
PS1="&# $PS1"
(peu importe que ça soit via le profile ou directement en interactif)
ce qui explique que certains n'arrivaient pas à reproduire le pb !
sais tu comment ça se fait ?
et il y a un autre pb :
c'est qu'apparemment, ce petit bug qui a été (en partie) corrigé, il
était à l'intérieur d'un plus gros bug qui ne l'a pas été :
si t'as tjr un fichier dont le nom contient un accent,
- commences par appuyer plusieurs fois sur entrée, de manière à faire
plusieurs lignes
- glisses le fichier autant de fois que nécessaire pour dépasser la
largeur du terminal
- ensuite, au choix, joues avec l'historique comme la dernière fois, ou
redimentionnes la fenêtre, dans les 2 sens
ça devrais te faire un beau bazar :-P
tiens moi au courant si t'as à nouveau besoin que je te fasse des copies
d'écran
> voilà, est ce que ceux qui veulent bien essayer réussissent à reproduire > mon pb ?
> il semblerait que certains réussissent à reproduire mon pb, mais pas > tous, > alors ce que j'aimerais, si tout le monde veut bien, > c'est trouver ce qu'il y a comme différences, entre les ordis qui ont le > pb et les ordis qui ne l'ont pas :-)
Cela provient d'un bug de la version de readline (5.1 - 2005 !) utilisée lors de la compilation de bash livré par défaut avec Mac OS X 10.6; qui on peut le dire, est relativement vieillotte (3.2.48 - novembre 2008).
Avec la dernière version de bash et celle de readline, le comportement est correct.
bon alors, je reprend ce msg ci, parce que voilà ce que j'ai trouvé :
apparemment, la version 3.2.48 a ce bug corrigé (en tout cas autant que la version 4)
par contre, ce bug resurgit si on exécute PS1="&# $PS1" (peu importe que ça soit via le profile ou directement en interactif)
ce qui explique que certains n'arrivaient pas à reproduire le pb !
sais tu comment ça se fait ?
et il y a un autre pb : c'est qu'apparemment, ce petit bug qui a été (en partie) corrigé, il était à l'intérieur d'un plus gros bug qui ne l'a pas été :
si t'as tjr un fichier dont le nom contient un accent, - commences par appuyer plusieurs fois sur entrée, de manière à faire plusieurs lignes - glisses le fichier autant de fois que nécessaire pour dépasser la largeur du terminal - ensuite, au choix, joues avec l'historique comme la dernière fois, ou redimentionnes la fenêtre, dans les 2 sens
ça devrais te faire un beau bazar :-P
tiens moi au courant si t'as à nouveau besoin que je te fasse des copies d'écran
par contre, ce bug resurgit si on exécute PS1="&# $PS1" (peu importe que ça soit via le profile ou directement en interactif)
ce qui explique que certains n'arrivaient pas à reproduire le pb !
sais tu comment ça se fait ?
Aucune idée car je n'utilise plus ce shell depuis pas mal d'années.
tiens moi au courant si t'as à nouveau besoin que je te fasse des copies d'écran
Non merci.
Puisque tu indiques qu'il reste toujours des bugs sur cette question-là, n'hésite pas à aider les développeurs de bash. Cf. <http://tiswww.case.edu/php/chet/bash/bashtop.html#Bugs>
-- echo '' | tr '[a-z]' '[n-za-m]'
On Sam 07 mai 2011, 20:58,
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
par contre, ce bug resurgit si on exécute
PS1="&# $PS1"
(peu importe que ça soit via le profile ou directement en interactif)
ce qui explique que certains n'arrivaient pas à reproduire le pb !
sais tu comment ça se fait ?
Aucune idée car je n'utilise plus ce shell depuis pas mal d'années.
tiens moi au courant si t'as à nouveau besoin que je te fasse des copies
d'écran
Non merci.
Puisque tu indiques qu'il reste toujours des bugs sur cette question-là,
n'hésite pas à aider les développeurs de bash.
Cf. <http://tiswww.case.edu/php/chet/bash/bashtop.html#Bugs>
par contre, ce bug resurgit si on exécute PS1="&# $PS1" (peu importe que ça soit via le profile ou directement en interactif)
ce qui explique que certains n'arrivaient pas à reproduire le pb !
sais tu comment ça se fait ?
Aucune idée car je n'utilise plus ce shell depuis pas mal d'années.
tiens moi au courant si t'as à nouveau besoin que je te fasse des copies d'écran
Non merci.
Puisque tu indiques qu'il reste toujours des bugs sur cette question-là, n'hésite pas à aider les développeurs de bash. Cf. <http://tiswww.case.edu/php/chet/bash/bashtop.html#Bugs>
-- echo '' | tr '[a-z]' '[n-za-m]'
Thomas
In article <iq4dle$cd0$, Matt wrote:
Puisque tu indiques qu'il reste toujours des bugs sur cette question-là, n'hésite pas à aider les développeurs de bash. Cf. <http://tiswww.case.edu/php/chet/bash/bashtop.html#Bugs>
merci :-)
pour la doc (en général, mais en particulier pour la branche de jeudi), désolé, j'ai pas encore le réflexe, tout simplement
In article <iq4dle$cd0$1@talisker.lacave.net>,
Matt <hfrarg@syrius.org.invalid> wrote:
Puisque tu indiques qu'il reste toujours des bugs sur cette question-là,
n'hésite pas à aider les développeurs de bash.
Cf. <http://tiswww.case.edu/php/chet/bash/bashtop.html#Bugs>
merci :-)
pour la doc (en général, mais en particulier pour la branche de jeudi),
désolé, j'ai pas encore le réflexe, tout simplement
Puisque tu indiques qu'il reste toujours des bugs sur cette question-là, n'hésite pas à aider les développeurs de bash. Cf. <http://tiswww.case.edu/php/chet/bash/bashtop.html#Bugs>
merci :-)
pour la doc (en général, mais en particulier pour la branche de jeudi), désolé, j'ai pas encore le réflexe, tout simplement
Puisque tu indiques qu'il reste toujours des bugs sur cette question-là, n'hésite pas à aider les développeurs de bash. Cf. <http://tiswww.case.edu/php/chet/bash/bashtop.html#Bugs>
bon alors, je ne comprend pas tout ce qu'on m'a répondu : http://lists.gnu.org/archive/html/bug-bash/2011-05/msg00050.html
est ce que qqn veut bien m'aider à décrypter svp ? :-) par exemple, comment savoir si "wcwidth" est bon, chez moi ? (et tout le reste, je n'en ai pas compris la moitié)
In article <iq4dle$cd0$1@talisker.lacave.net>,
Matt <hfrarg@syrius.org.invalid> wrote:
Puisque tu indiques qu'il reste toujours des bugs sur cette question-là,
n'hésite pas à aider les développeurs de bash.
Cf. <http://tiswww.case.edu/php/chet/bash/bashtop.html#Bugs>
bon alors, je ne comprend pas tout ce qu'on m'a répondu :
http://lists.gnu.org/archive/html/bug-bash/2011-05/msg00050.html
est ce que qqn veut bien m'aider à décrypter svp ? :-)
par exemple, comment savoir si "wcwidth" est bon, chez moi ?
(et tout le reste, je n'en ai pas compris la moitié)
Puisque tu indiques qu'il reste toujours des bugs sur cette question-là, n'hésite pas à aider les développeurs de bash. Cf. <http://tiswww.case.edu/php/chet/bash/bashtop.html#Bugs>
bon alors, je ne comprend pas tout ce qu'on m'a répondu : http://lists.gnu.org/archive/html/bug-bash/2011-05/msg00050.html
est ce que qqn veut bien m'aider à décrypter svp ? :-) par exemple, comment savoir si "wcwidth" est bon, chez moi ? (et tout le reste, je n'en ai pas compris la moitié)
bon alors, je ne comprend pas tout ce qu'on m'a répondu : http://lists.gnu.org/archive/html/bug-bash/2011-05/msg00050.html
est ce que qqn veut bien m'aider à décrypter svp ? :-) par exemple, comment savoir si "wcwidth" est bon, chez moi ? (et tout le reste, je n'en ai pas compris la moitié)
D'après la constatation de Chet Ramey, cela provient d'un bug des librairies « mbrtowc » et « wcwidth » :
« The fact that mbrtowc and wcwidth can't seem to tell the redisplay code that there's a combining character is the problem. It fools redisplay into miscalculating where the lines actually begin to differ.
(FWIW, I'm using MacOS X and Terminal.) »
Bash les utilisant pour rafraîchir l'affichage, ça pose problème dès qu'un caractère combiné (tel que nos caractères avec accents, par exemple) est affiché.
-- echo '' | tr '[a-z]' '[n-za-m]'
On Jeu 12 mai 2011, 14:37,
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
bon alors, je ne comprend pas tout ce qu'on m'a répondu :
http://lists.gnu.org/archive/html/bug-bash/2011-05/msg00050.html
est ce que qqn veut bien m'aider à décrypter svp ? :-)
par exemple, comment savoir si "wcwidth" est bon, chez moi ?
(et tout le reste, je n'en ai pas compris la moitié)
D'après la constatation de Chet Ramey, cela provient d'un bug des
librairies « mbrtowc » et « wcwidth » :
« The fact that mbrtowc and wcwidth can't seem to tell the redisplay
code that there's a combining character is the problem. It fools
redisplay into miscalculating where the lines actually begin to
differ.
(FWIW, I'm using MacOS X and Terminal.) »
Bash les utilisant pour rafraîchir l'affichage, ça pose problème dès
qu'un caractère combiné (tel que nos caractères avec accents, par
exemple) est affiché.
bon alors, je ne comprend pas tout ce qu'on m'a répondu : http://lists.gnu.org/archive/html/bug-bash/2011-05/msg00050.html
est ce que qqn veut bien m'aider à décrypter svp ? :-) par exemple, comment savoir si "wcwidth" est bon, chez moi ? (et tout le reste, je n'en ai pas compris la moitié)
D'après la constatation de Chet Ramey, cela provient d'un bug des librairies « mbrtowc » et « wcwidth » :
« The fact that mbrtowc and wcwidth can't seem to tell the redisplay code that there's a combining character is the problem. It fools redisplay into miscalculating where the lines actually begin to differ.
(FWIW, I'm using MacOS X and Terminal.) »
Bash les utilisant pour rafraîchir l'affichage, ça pose problème dès qu'un caractère combiné (tel que nos caractères avec accents, par exemple) est affiché.
