• # oui

    Posté par  . Évalué à 9.

    Oui, c'est un bug connu
    http://us.generation-nt.com/bug-531721-bash-glob-pattern-z-m(...)
    le problème est que quand tu fais un rm -rf [A-Z]*, ca supprime aussi ton répertoire porn parce que la casse n'est pas respecté.

    c'est hallucinant que ce problème existe. Je suis perturbé et je commence à douter de mon shell.

    • [^] # Re: oui

      Posté par  . Évalué à 10.

      En même temps, c'est pas UTF-8, le problème… C'est bash.
      Sur zsh, aucun problème.

      • [^] # Re: oui

        Posté par  . Évalué à 5.

        Ah oui, c'est pas mal. Surtout sur mac os x, avec un système de fichier insensible à la casse.

        Quand on fait touch a A B b, on obtient un fichier a, et un fichier B. et ls [A-Z] montre bien que le fichier B.

        Envoyé depuis mon lapin.

        • [^] # Re: oui

          Posté par  (site web personnel) . Évalué à 1.

          Bonsoir,

          Ah oui, c'est pas mal. Surtout sur mac os x, avec un système de fichier insensible à la casse.

          Tu n'es pas obligé d'utiliser un système de fichier qui ne tiens pas compte de la case.

          Je ne suis même pas certain que ce soit ce choix par défaut... si ça se trouve oui...

          Bon, en même temps, il y a d'autres bugs avec l'un ou l'autre.... incroyable qu'il y ait encore des gens pour utiliser MacOS X pour travailler.

          A bientôt
          Grégoire

          Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

          • [^] # Re: oui

            Posté par  . Évalué à 5.

            Je ne suis même pas certain que ce soit ce choix par défaut... si ça se trouve oui...

            Oui, le système de fichier ne tient pas compte de la casse par défaut et si tu choisis de tenir compte de la casse, certains programmes comme Photoshop ne s'installent pas.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: oui

        Posté par  . Évalué à 2.

        Ou la libc. Bash utilise peut etre la fonction "glob" ...
        Mais bon des que l'on sort de la locale ASCII, il y a tout un tas de pb avec le pattern matching (lower/upper, range, ...)

      • [^] # Re: oui

        Posté par  . Évalué à 2.

        Sur dash aussi, aucun problème.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 0.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: oui

          Posté par  . Évalué à 3.

          la norme POSIX se fout de ce qui se passe en dehors de la locale POSIX ?

          non, le problème, ce sont toutes ces locales non-POSIX

    • [^] # Re: oui

      Posté par  . Évalué à 7.

      Deux choses qui me choquent:

      1. Le rapport de bug que tu pointes date de juin 2009, personne ne s'en est rendu compte avant?
      C'est pas que de mon bash que je vais avoir peur, c'est des scripts actifs sur serveurs dans le monde entier.

      2. Même ce rapport a presque 1 an. J'ai pas de bash sous la main, mais visiblement, ce n'est toujours pas corrigé ?!?
      C'est quoi l'astuce?
      - Trop de scripts qui utilisent le code foireux et qui marcheraient plus si c'était corrigé?
      - Apparemment autorisé par POSIX, alors circulez y'a rien à voir?

      Et après ça on critique MS parce qu'ils tentent de laisser des bugs de fonctionnement en parallèle avec la solution pour éviter d'avoir des problèmes chez les clients qui prennent le bug en compte au développement.
      C'est vraiment pas mieux chez nous là, c'est pas comme si Bash n'était pas un élément important dans la majorité des distributions!!

      • [^] # Re: oui

        Posté par  . Évalué à 3.

        La différence c'est que là, tu peux proposer un patch, utiliser ta version patchée etc... Sous windows, si il y a un gros bug qui est vraiment bloquant pour toi et qu'ils ne veulent corriger, ben...heu... tu changes de systèmes?

        • [^] # Re: oui

          Posté par  . Évalué à 10.

          Oui mais justement, tout ce que tu viens de dire, je le sais déjà, et le fait est que... il ne s'est rien passé!

          - Je propose un patch:
          HA HA HA HA!
          Nan mais tu m'as jamais vu programmer toi. D'ailleurs personne ne m'a jamais vu programmer, c'est bien le problème...

          - J'utilise UNE version patchée (mais pas la mienne, cf ci-dessus)
          * Alors, comme je le disais: quid de tous les scripts qui utilisent ça et prennent le bug en compte? Que vont-ils faire avec ma version patchée? Des surprises?
          * Je patche ma version, une nouvelle version sort. Soit je bloque la mise à jour et je garde ma version, sois je me retape le boulot pour la nouvelle version. C'est le problème des versions patchées: faut suivre ce que fait l'amont.

          - La différence entre un bon système et un mauvais système, c'est que dans le mauvais système, y'a un bug, tu vis avec. On les reconnait à 100m, dès que ça bugue, tu sais que tu vas devoir vivre avec.
          Tandis qu'un bon système, y'a un bug... bon, tu vis avec, mais c'est un bon système!
          Faut bien leur expliquer aux gens, parce qu'après ils font pas la différence!

          Je sais bien qu'en général, ce n'est pas le cas et que les bugs sont corrigés rapidement. Mais pBpG ne devrait pas tarder à rappliquer pour t'expliquer que sous Windows, quand le bug est gros et gênant, ben on le laisse pas trainer là non plus...

  • # Hmmm oui mais …

    Posté par  . Évalué à 6.

    Hmm oui, mais encore ?

    Si ça se résume à ça ta pensée, ça ira pas bien loin la discussion, et au vu des nombreux avantages qu'apporte l'utf8 je pense que tu est pas près de faire sans.

    • [^] # Re: Hmmm oui mais …

      Posté par  . Évalué à -10.

      C'est quoi les avantages de l'utf8 ? Pouvoir mélanger un texte en klingon avec du slovaque ?

      Et pourquoi la glibc est totalement buggée à ce niveau ?

      • [^] # Re: Hmmm oui mais …

        Posté par  . Évalué à 10.

        Je suis Français, qui aime mes caractères accentués comme il faut, et j'habite en Chine, et j'écris (un tout petit peu) en Chinois sur ordinateur.

        Et bien moi je te garantis que l'UTF-8, c'est de la balle!!

      • [^] # Re: Hmmm oui mais …

        Posté par  . Évalué à 10.

        Pouvoir lire un texte en n'importe quelle langue ? Pouvoir même les mélanger dans un même document ? Éviter les emmerdes de conversions d'un encodage obscur à un autre avant de pouvoir utiliser un fichier ? (tu as déjà essayé de lire un fichier de sous-titre en chinois ? Déjà comparé XeLaTeX à LaTeX pour autre chose que l'alphabet latin ?)

        Je suis aussi un français vivant en Chine, et UTF-8 est vraiment utile. Et c'est vraiment utile qu'il soit géré partout, y compris dans mon shell. Oui j'ai des fichiers et des dossiers avec des noms en chinois, et je m'en sers tous les jours. Bon, j'avoue que je ne tente pas trop d'expressions rationnelles dessus quand même ...

        Ceci dit, j'utilise Zsh, donc je n'ai pas ce bug ;o)

        • [^] # Re: Hmmm oui mais …

          Posté par  . Évalué à 3.

          je suis complètement du même avis, pour ma part, mon système est en japonais et l'UTF-8 est la garantie d'une vie sans problèmes d'encodages. Idem avec mon Zsh, aucun problème :)

  • # ton journal puxor

    Posté par  (site web personnel) . Évalué à 9.

    Ce n'est pas constructif, ce qui était a dire a déja été dit (ce n'est pas l'utf8, c'est bash), mais j'avais envie.

    • [^] # Re: ton journal puxor

      Posté par  (site web personnel) . Évalué à 10.

      Mais non il a raison.

      L'UTF-8, c'est bien plus complexe (même si ça permet plus de trucs), donc c'est plus compliqué à implémenter, donc c'est plus plantogène.

      Bref, l'UTF8, sapu.

      C'est comme comparer mes rollers avec le porte avions Charles de Gaulle. Les premiers sont comme neufs et ne m'ont jamais fait défaut. Quant au porte avions, il y a un problème tous les deux ans.

      C'est bien la preuve de la supériorité technique de mes rollers sur le porte avions.

      D'ailleurs si on veut faire la guerre, il faudra équiper nos soldats de rollers.

      • [^] # Re: ton journal puxor

        Posté par  (site web personnel) . Évalué à 5.

        J'aime ton commentaire.

        Dans le genre bug débile lié à la localisation abracadabrante de la libc, on m'a montré celui-là qui est interessant:

        http://daniel.haxx.se/blog/2008/10/15/strcasecmp-in-turkish/

        Si j'avais dû en faire un journal, je l'aurais intitulé "libc puxor"

        • [^] # Re: ton journal puxor

          Posté par  . Évalué à 4.

          Là c'est plutôt lié aux locales turques qui sont effectivement partiellement incompatibles avec ASCII, ce qui les rend délicates à utiliser.
          On a le même genre de problèmes avec Python :
          http://bugs.python.org/issue1813

          Notons qu'un strcasecmp pur ASCII n'est pas trop difficile à recoder à la main :)

      • [^] # Re: ton journal puxor

        Posté par  . Évalué à 6.

        C'est surtout que ça va être compliqué de faire traverser les mers à des avions de chasse montés sur rollers.

        Y'en a qui ont essayé, ils ont eu des problèmes...

        • [^] # Re: ton journal puxor

          Posté par  (site web personnel) . Évalué à 10.

          Pas du tout.


          Les pilotes sont en train de battre des records du monde d'apnée en ce moment même.


          On ne sait pas encore de combien, mais quand ils remonteront, ils vont péter les scores.

  • # Contournement particulier

    Posté par  . Évalué à 8.

    utiliser "ls [[:upper:]]'" à la place de "ls [A-Z]" semble fonctionner

    • [^] # Re: Contournement particulier

      Posté par  . Évalué à 9.

      Oh, ls utilise les [:totoz], [:supaire]!

      (Sinon c'est super intuitif de matcher les minuscules avec [A-Z].)

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Problème de niveaux

    Posté par  (site web personnel) . Évalué à 10.

    Il y a trois niveaux dans le systeme :
    1) Le logiciel qui interprete (ton shell)
    2) Le conteneur de chaine (UTF-8)
    3) L'encodage des caractères (UNICODE)
    Dans ton problème c'est 1) qui merde car il gère mal 3) et toi tu accuse 2).

    L'UTF8 est un très bon conteneur pour l'UNICODE avec énormément d'avantages. Le problème est qu'il n'est pas toujours bien utilisé.

    Mais bon, la source principale de ce problème est la complexité d'UNICODE qui traine derière lui une longue histoire et donc des problèmes de compatibilités. Lorsque l'ASCII à été défini, ils ont définit la position des caractères alphabétiques de manière à pouvoir réaliser plein d'opérations courrantes de manière simple.
    Maintenant que tout le monde se préoccupe un peu plus du reste du monde, il y a un peu plus de caractères alphabétiques et il n'est plus vraiment possible de faire les choses aussi simplement. Le problème est que tout le monde reste habitué à la manière simple de gérer les choses.
    Je ne compte pas le nombre de programe que je vois faire un test sur des bits à la place d'un isupper (ou plutôt d'un wisupper).

    L'exemple que tu donne montre deux bugs : le premier viens de bash qui ne fait pas ce qu'on lui demande, mais le second viens de ce que tu lui demande. Utiliser [A-Z] pour tester une majuscule c'est aller au devans des ennuis dans tous les cas.

    • [^] # Re: Problème de niveaux

      Posté par  . Évalué à 2.

      >>> Utiliser [A-Z] pour tester une majuscule c'est aller au devans des ennuis dans tous les cas.

      Admettons, donc, c'est quoi la bonne méthode pour récupérer les fichiers A et B sans a et b.

      Et dans le cas d'un touch A a B b C c D d, comment faire pour matcher A, B et C seulement eux ? Perso un ls [A-C] me semble normal.

      C'est la fin des regexp ?

      • [^] # Re: Problème de niveaux

        Posté par  . Évalué à 1.

        Perso un ls [A-C] me semble normal.

        Moi aussi. C'est visiblement une couille dans bash.

        • [^] # Re: Problème de niveaux

          Posté par  (site web personnel) . Évalué à 9.

          Ça dépend comment tu définis [A-C]. Manifestement, c'est toutes les lettres entre A et C, dans l'ordre de la locale. Hors beaucoup de locales ignorent la casse quand elles ordonnent les lettres, et dans l'exemple donné, [A-C] correspond alors à [AaBbC], voire même à [AaÀàÁáÂâÃãÄäÅåBbC].

          C'est donc pas forcément une « couille dans bash », mais un problème de spécification, ou un problème de se servir de quelque chose sans avoir réellement vérifié à quoi il correspondait (je m'inclus dans ce dernier cas).

          • [^] # Re: Problème de niveaux

            Posté par  . Évalué à 4.

            [A-C] est en effet un intervalle et [A,B,C] ne contiendra que A, B et C (et [A,C] ne contiendra pas B...)

            avec les accents ca devient vite rigolo, pratiquement chaque pays ou langage a un ordre de tri des caractères, le Portugal en a même deux...

      • [^] # Re: Problème de niveaux

        Posté par  (site web personnel) . Évalué à 4.

        Admettons, donc, c'est quoi la bonne méthode pour récupérer les fichiers A et B sans a et b.

        Dans le cas ou tu sais à l'avance que tu veux récupérer A et B, la seule manière compatible avec toutes les locale c'est de lister explicitement les fichiers : [AB]

        Et dans le cas d'un touch A a B b C c D d, comment faire pour matcher A, B et C seulement eux ? Perso un ls [A-C] me semble normal.

        La bonne manière ici c'est juste [ABC]. Il faut bien comprendre que les ranges ne sont absolument pas portable entre les locales.

        Quand tu fais [A-C], tu demande tous les fichiers de 1 caractère compris entre A et C dans la locale courante, donc ce que tu obtiens est cohérent avec la locale, mais pas forcément avec la logique ASCII qui ne travaillait qu'avec un tout petit jeu de caractère.

        La compléxité de l'UNICODE introduit de nombreux autres problèmes dans ce genre de cas. et même en utilisant [:upper:], il faut faire attention puisqu'il y a trois niveaux de capitalisation : lowercase, uppercase et titlecase.

  • # Le pourquoi du bug...

    Posté par  . Évalué à 5.

    Ulrich Drepper vous explique tout : https://bugzilla.redhat.com/show_bug.cgi?id=217359

  • # what puxor ?

    Posté par  (site web personnel) . Évalué à 0.

    Je propose la création d'un nouveau groupe : bash puxor

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.