GNU Sortie de GNU grep 2.7

Posté par . Modéré par baud123.
32
21
sept.
2010
GNU
La version GNU de grep vient de sortir en version 2.7. Outre les habituelles corrections de bugs (accessibles en cliquant sur "lire la suite" ) , deux évolutions ont été apportées :
  1. La première évolution consiste à lever une erreur lors de l'utilisation de [:space:], [:digit:], etc. au lieu de [[:space:]] ou [[:digit:]], etc. : jusqu'ici, cela n'était pas reconnu une erreur mais était interprété de façon POSIX ([:digit:] représentait n'importe quel caractère parmi ':', 'd', 't', 'g' et 'i') ; l'ancien comportement peut être conservé en positionnant la variable d'environnement POSIXLY_CORRECT.
  2. La seconde évolution intéressera beaucoup les francophones, puisqu'il s'agit de la possibilité d'utiliser les équivalences définies par les locales, et donc de détecter les caractères accentués en indiquant juste la lettre correspondante ; il est à noter que cette fonctionnalité n'est disponible qu'en utilisant la glibc et en positionnant la locale souhaitée.
Traduction corrections de bugs annoncées :

grep --include=FILE fonctionne à nouveau, et n'agit plus comme --exclude=FILE
[bug introduit dans grep-2.6]

Une recherche de chaîne vide avec grep -Fw ne retournera plus de lignes vides. [bug présent depuis "le début"]

X{0,0} est correctement implémenté. Il était utilisé comme synonyme de X{0,1}.
[bug présent depuis "le début"]

Avec les locales multi-octets, les expressions rationnelles incluant des références arrières ne génèrent plus une complexité quadratique (NdT : cf. Théorie_de_la_complexité_des_algorithmes)
[bug présent depuis que le support des caractères multi-octets a été introduit dans 2.5.2]

Avec les locales UTF-8, les expressions rationnelles incluant "." sont traitées plus rapidement. Par exemple, grep . est maintenant deux fois plus rapide que grep -v ^$, au lieu d'être beaucoup plus lent. Cela reste lent avec les autres locales multi-octets.
[bug présent depuis que le support des caractères multi-octets a été introduit dans 2.5.2]

--mmap devait être ignoré depuis 2.6.x, mais il avait été supprimé par erreur.
[bug introduit dans 2.6]


Note : merci aux modérateurs d'avoir remis en forme l'article, la syntaxe des regexp étant parfois en conflit avec celle de mise en forme des articles, l'auteur de ces lignes n'a pas réussi à s'en sortir...
(23 commentaires).

  • # Complexité

    Posté par (page perso) . Évalué à 2.

    Est-il possible de connaître la nouvelle complexité avec référence en arrière?

    Sinon : "l'ancien comportement peut-être conservé" => l'ancien comportement peut être conservé.

    Merci pour la nouvelle, en tout cas!

    • [^] # Re: Complexité

      Posté par . Évalué à 2.

      Si je me rappelle bien ce que j'avais lu sur le problème des performances avec les références arrières pour Perl, il existe un algo logarithmique pour faire cela:

      http://swtch.com/~rsc/regexp/regexp1.html
      Mais en fait, cela semble parler de grep 2.5.1 qui a déjà un comportement logarithmique, donc en fait, on ne parle peut être pas de la même chose. :(

  • # bug ?

    Posté par (page perso) . Évalué à 10.

    « X{0,0} est correctement implémenté. Il est utilisé comme synonyme de X{0,1}. »

    Une évidence m’échappe peut-être, mais… je ne vois pas en quoi cette implémentation est correcte. X{0,0} veut dire : X au moins 0 fois (donc facultatif) et au plus 0 fois (donc interdit) ; l’implémenter en synonyme de X{0,1} me paraît faux !
    Et cela peut même être très gênant dans le cas d’expressions rationnelles générées par programme pour des contrôles dépendants de paramètres en entrée d’un traitement.

    Yves.

    • [^] # Re: bug ?

      Posté par . Évalué à 10.

      En fait je me suis trompé en écrivant la dépêche, il faut lire "il était utilisé comme synonyme de X{0,1}".

  • # Pas que les francophones quand même :)

    Posté par (page perso) . Évalué à 5.

    Heu, les équivalences ne sont pas utiles qu'au francophones seulement,
    hein :) Ce n'est d'ailleurs pas limité à l'alphabet latin, chaque
    communauté derrière une locale peut discuter avec le Common Locale Data
    Repository pour décider des équivalences :)

    Sinon, un petit exemple:
    echo é | grep \[\[=e=\]\]
    -> é

  • # de quoi s'agit il ?

    Posté par (page perso) . Évalué à 5.

    ça serait pas mal de dire en une ligne dans la dépêche e quoi il s'agit pour ceux qui ont manqué le début... merci !

  • # Sed est meilleur que grep

    Posté par (page perso, jabber id) . Évalué à 2.

    l'ancien comportement peut-être conservé
    s/peut-être/peut être/

    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

  • # Équivalence

    Posté par (page perso, jabber id) . Évalué à 1.

    Avec les locales UTF-8, les expressions rationnelles incluant "." sont traitées plus rapidement. Par exemple, grep . est maintenant deux fois plus rapide que grep -v ^$, au lieu d'être beaucoup plus lent.

    C'est moi ou "." ça n'a rien à voir avec "^$" ? Je dirais même que c'est l'inverse en quoi l'un devrait être plus rapide que l'autre ?

    Ça veut dire qu'il vaut mieux utiliser grep -v '.' que grep '^$' ?

    Égoïste, irresponsable décerné par devnewton

    • [^] # Re: Équivalence

      Posté par (page perso) . Évalué à 6.

      > C'est moi ou "." ça n'a rien à voir avec "^$" ? Je dirais même que c'est l'inverse en quoi l'un devrait être plus rapide que l'autre ?

      Oui, "." est précisément l'inverse de "^$", d'où la comparaison entre grep . et grep -v "^$" (le -v sert justement à inverser la sélection) qui font du coup la même chose : récupérer les lignes non vides.

      > Ça veut dire qu'il vaut mieux utiliser grep -v '.' que grep '^$' ?

      Le premier est probablement plus rapide que le deuxième, mais j'imagine que la différence dans la pratique va être négligeable à moins d'avoir un fichier dont on veut récupérer beaucoup de lignes vides, ce qui ne doit pas arriver souvent.

      • [^] # Re: Équivalence

        Posté par (page perso, jabber id) . Évalué à 0.

        >> Oui, "." est précisément l'inverse de "^$", d'où la comparaison entre grep . et grep -v "^$"

        L'inverse ? Le complément ?
        L'inverse de ^$, c'est .+.
        L'inverse de « rien, » c'est « au moins un caractère. »

        Non ?
        (Après, certes, si tu matches un caractère, tu en matches aussi deux… Mais c'est dû au comportement de grep qui ne cherche pas à considérer uniquement les mots du langage qu'on veut matcher comme des lignes lignes entières.)

      • [^] # Re: Équivalence

        Posté par (page perso, jabber id) . Évalué à 2.

        Je suis un boulet j'avais pas vu le -v dans l'exemple. Merci

        Égoïste, irresponsable décerné par devnewton

Envoyer un commentaire

Suivre le flux des commentaires

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