- 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.
- 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.
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...
Aller plus loin
- grep (16 clics)
- Liste des miroirs GNU (4 clics)
- Log git des modifications (6 clics)
# Complexité
Posté par mgoeminne (site web personnel) . Évalué à 2.
Sinon : "l'ancien comportement peut-être conservé" => l'ancien comportement peut être conservé.
Merci pour la nouvelle, en tout cas!
[^] # Re: Complexité
Posté par djano . Évalué à 2.
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 Yves (site web personnel) . Évalué à 10.
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 Denis Dordoigne . Évalué à 10.
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
# Pas que les francophones quand même :)
Posté par Samuel Thibault (site web personnel) . Évalué à 5.
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 antistress (site web personnel) . Évalué à 5.
[^] # Re: de quoi s'agit il ?
Posté par calandoa . Évalué à 10.
[^] # Re: de quoi s'agit il ?
Posté par j_kerviel . Évalué à 10.
Le héros manipule plein de strings
D'ailleurs si on le less faire, il va se retrouver en sleep, un join à la main.Mais heureusement kill s'en sort toujours et parvient finalement à échapper à la more
[^] # Re: de quoi s'agit il ?
Posté par FReEDoM (site web personnel) . Évalué à 4.
[^] # Re: de quoi s'agit il ?
Posté par Gniarf . Évalué à 3.
[^] # Re: de quoi s'agit il ?
Posté par campagnard . Évalué à 10.
On a tous été débutant un jour !
Pour ta réponse, antistress, voir ici : grep
[^] # Re: de quoi s'agit il ?
Posté par daimrod . Évalué à 10.
[^] # Re: de quoi s'agit il ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
http://www.nojhan.net/geekscottes/index.php?id=125
"La première sécurité est la liberté"
[^] # Re: de quoi s'agit il ?
Posté par vpo . Évalué à 3.
Il aurait ainsi pu avoir comme premier résultat de sa recherche l’articule grep de Wikipedia Fr s'il ne lit pas l'anglais.
[^] # Re: de quoi s'agit il ?
Posté par contre_maitre . Évalué à 4.
C'est quand même plus agréable.
[^] # Re: de quoi s'agit il ?
Posté par Maclag . Évalué à 10.
On a tous été débutant ET égaré sur internet un jour!
[^] # Re: de quoi s'agit il ?
Posté par Guillaume Knispel . Évalué à 8.
Il eut été un temps où l'on débutait en apprenant notamment ce qu'est "grep".
Quand à savoir si c'était mieux ainsi ou maintenant...
# Sed est meilleur que grep
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
s/peut-être/peut être/
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Sed est meilleur que grep
Posté par Elfir3 . Évalué à 4.
=>[]
# Équivalence
Posté par barmic . Évalué à 1.
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 '^$' ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Équivalence
Posté par Bruno Michel (site web personnel) . Évalué à 6.
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 Axioplase ıɥs∀ (site web personnel) . Évalué à 0.
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 barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.