ripgrep 15.0

(github.com/BurntSushi)

2 points par GN⁺ 2025-10-19 | 1 commentaires | Partager sur WhatsApp

ripgrep 15.0 est une version majeure qui inclut diverses mises à jour, notamment des corrections de bugs, des améliorations de performances et de nouvelles fonctionnalités
De nombreux bugs liés à l’application des règles gitignore ont été corrigés, et une optimisation mémoire a été effectuée pour le traitement des fichiers volumineux
La prise en charge de la plateforme Windows aarch64 a été ajoutée, tandis que la prise en charge de powerpc64 a été abandonnée
Parmi les nouvelles fonctionnalités figurent la prise en charge simultanée de --json et des drapeaux de remplacement, ainsi que la prise en charge des accolades imbriquées dans les globs
Les améliorations globales des performances, les corrections d’erreurs et les gains d’ergonomie augmentent la productivité des développeurs

Vue d’ensemble de ripgrep 15.0

ripgrep 15.0 est la dernière version majeure de ripgrep, qui comprend principalement des corrections de bugs, de légères améliorations de performances et l’ajout de petites nouvelles fonctionnalités

ripgrep est un outil qui recherche récursivement des motifs d’expressions régulières, ligne par ligne, dans le répertoire courant
Par défaut, il respecte les règles gitignore et ignore automatiquement les fichiers/répertoires cachés ainsi que les fichiers binaires

Principaux changements

Plusieurs bugs liés au matching de gitignore ont été corrigés
- Résolution d’un bug fréquemment signalé concernant l’application des règles gitignore des répertoires parents
Le bug d’augmentation de l’utilisation mémoire lors du traitement de très gros fichiers gitignore a été corrigé
rg -vf file a été modifié pour tout faire correspondre lorsque file est vide
Le drapeau -r/--replace fonctionne désormais correctement avec --json
Certains dépôts Jujutsu (jj) sont désormais reconnus comme des dépôts Git, ce qui permet à ripgrep de suivre le gitignore de jj
Les globs prennent désormais en charge les accolades imbriquées

Prise en charge des plateformes

De nouveaux binaires de release sont fournis pour Windows aarch64
Les binaires de release pour powerpc64 ne sont plus fournis
- Arrêt dû à des problèmes dans le workflow CI de release ; il est possible d’en faire la demande si des tests et un support sont souhaités
Les binaires ripgrep sont compilés avec LTO (Link Time Optimization), ce qui apporte un léger gain de performances et une réduction de taille

Améliorations des performances

Sur Windows, les performances sont améliorées lorsque l’option -z/--search-zip n’est pas utilisée, grâce à la désactivation de la recherche de binaires auxiliaires
Sur Windows, l’absence de normalisation des chemins lors de l’affichage des hyperliens améliore la vitesse
Les performances sont améliorées pour le traitement de grandes valeurs lors de l’utilisation de -A/--after-context

Corrections de bugs

Correction de nombreux problèmes liés à gitignore, notamment la non-application du gitignore des répertoires parents
La commande rg -vf file sur un fichier vide a été corrigée pour tout faire correspondre
Ajout de la prise en charge de l’ignorance du marqueur BOM UTF-8 dans .gitignore et autres fichiers similaires
Optimisation de l’utilisation mémoire lors du traitement de gros fichiers gitignore
Correction d’une erreur d’affichage du nombre d’octets recherchés avec --stats
Correction d’une erreur dans le traitement des globs se terminant par .
Résolution d’un problème d’indication de dépassement du nombre de correspondances avec la combinaison -m/--max-count et -U/--multiline
Le drapeau -r/--replace a été modifié pour préserver les fins de ligne
Résolution d’une erreur d’inversion du code de sortie avec la combinaison -q --files-without-match
Correction d’une incohérence de documentation entre -c/--count et --files-with-matches
Correction d’un problème rare de panic avec de grandes expressions régulières et de grosses entrées
Échappement des tirets dans les noms de drapeaux d’option dans la page man
Compilation statique de PCRE2 dans la release macOS aarch64
Correction d’un bug du filtre d’ignorance des répertoires parents lors de la recherche de fichiers cachés mis en liste blanche
Correction de statistiques récapitulatives incorrectes lors de l’utilisation du drapeau --json
Correction d’erreurs de traitement de gitignore lors de la recherche avec des chemins absolus et dans le gitignore global
Correction d’un problème de panic avec la combinaison -U/--multiline et -r/--replace

Améliorations fonctionnelles

L’ensemble par défaut des types de fichiers a été largement étendu et amélioré
-r/--replace a été amélioré pour être compatible avec --json
L’autocomplétion de fish shell a été améliorée pour prendre en compte le fichier de configuration de ripgrep
italic a été ajouté aux attributs de style utilisables avec --color
Le répertoire .jj est traité comme un dépôt Git
En cas d’utilisation du multithreading, ajout d’une fonctionnalité permettant de planifier la recherche dans l’ordre des fichiers spécifié en CLI
Ajout des artefacts de release aarch64 pour Windows
Ajout du type de couleur highlight, qui permet de styliser le texte non correspondant dans les lignes contenant une correspondance
Ajout de la fonctionnalité d’alternatives imbriquées dans les crates globs et globset
L’autocomplétion de --hyperlink-format a été améliorée dans bash, fish et zsh

1 commentaires

GN⁺ 2025-10-19

Avis sur Hacker News

ripgrep est un outil qui m’a vraiment fait gagner énormément de temps ces dernières années ; c’est l’un des tout premiers outils que j’installe quand je démarre un nouveau système, et il est indispensable, surtout pour explorer d’anciennes bases de code ; mon seul regret, c’est qu’avec l’option -F (traitement littéral), certains caractères semblent encore parfois être traités comme des caractères spéciaux nécessitant un échappement ; je ne me souviens plus exactement lesquels, mais je suis toujours heureux de voir ripgrep continuer à être mis à jour
- Si vous pouvez donner un exemple du caractère qui posait problème, je peux l’expliquer plus précisément ; -F/--fixed-strings désactive à 100 % les fonctionnalités d’expression régulière dans le motif et le traite uniquement comme du littéral ; s’il faut échapper quelque chose, c’est probablement le shell qui l’exige
rg donne l’impression d’être magique ; en réalité, c’est le résultat d’une ingénierie exceptionnelle, d’améliorations continues, et d’une exploitation maximale des performances matérielles incroyables que nous utilisons tous au quotidien ; c’est aussi une innovation qui a ouvert la voie à une navigation et une compréhension du code plus rapides pour les développeurs, sans avoir besoin de créer un standard séparé comme lsp
- Je me demande vraiment ce que signifie « smithing » dans ce contexte
La base de code de ripgrep est un exemple parfait du genre « préparez-vous une boisson, installez-vous dans votre fauteuil le plus confortable et partez lire du logiciel de haute qualité » ; on clique partout dans le code en admirant ce qu’on voit
- Cet article de blog est aussi une lecture vraiment excellente
Comme fd, rg est un outil en ligne de commande réellement agréable à utiliser ; j’aime beaucoup ces nouveaux outils orientés commandes
- J’ai appris récemment que les auteurs de ripgrep et de fd travaillent chez Astral ; ça explique pourquoi les logiciels d’Astral sont aussi bons
- Les deux outils font, par défaut et sans options particulières, exactement ce que je veux dans 99 % des cas ; c’est un énorme gain de temps ; par exemple, taper simplement rg <string> ou fd <string> suffit
La fonctionnalité que j’aimerais personnellement voir ajoutée est un drapeau « extension » : quelque chose qui fonctionnerait comme -g, mais traiterait l’argument d’entrée comme une extension (par exemple : rg -e c,h) ; la plupart du temps, quand on utilise des motifs glob, c’est pour faire correspondre des extensions
- Je me demande si vous avez déjà vu le drapeau -t/--type ; on peut l’utiliser comme -tc dans votre exemple ; et si l’extension n’existe pas dans ripgrep, on peut aussi définir son propre type
ripgrep a été l’une des principales raisons pour lesquelles j’ai commencé à m’intéresser à rust ; il fonctionnait avec un tel niveau de finition que le fait qu’il soit écrit en rust a éveillé encore plus ma curiosité ; plusieurs années plus tard, j’utilise toujours rg tous les jours
- nibbles a été l’une des principales raisons pour lesquelles je me suis intéressé à qbasic ; c’était tellement abouti que le fait qu’il soit écrit en qbasic m’a intrigué, et grâce à cela, j’utilise nibbles tous les jours
J’ai découvert récemment l’option --replace, et j’ai été assez impressionné ; en l’utilisant avec --type, je me suis dit que c’était dommage de ne pas avoir su plus tôt que ce genre de fonctionnalités existaient ; à l’avenir, je compte lire les notes de version plus attentivement pour mieux repérer les nouveautés ; je suis aussi heureux des améliorations d’intégration avec jj
C’est un excellent outil, tout en restant très simple à utiliser ; j’ai commencé à l’utiliser sur Linux, et maintenant je l’utilise aussi sur Windows ; grâce à cet outil, je fais désormais directement des recherches avec des expressions régulières au lieu d’utiliser des jokers
- C’est mieux que grep de base, et la commande rg --files est aussi utile
Cette semaine, j’ai créé une fonction bash pour exécuter ripgrep uniquement sur les fichiers suivis par git
```
  rgg() {
    readarray -d '' -t FILES < <(git ls-files -z)
    rg "${@}" "${FILES[@]}"
  }
```
Cela permet de chercher bien plus vite dans les répertoires contenant beaucoup de fichiers binaires ou de fichiers cachés ; pour rechercher dans les fichiers cachés, il faut l’option -uu, mais cette option fait aussi chercher dans les fichiers binaires ; quand il y a plusieurs centaines de fichiers, git ls-files lui-même devient lent
- Je serais curieux d’avoir un exemple concret où cela va effectivement plus vite ; en général, ripgrep respecte déjà les règles de gitignore, donc son comportement ressemble à celui de git ls-files ; à noter que l’option -uu signifie que ripgrep doit ignorer gitignore et les fichiers cachés, mais il saute toujours les fichiers binaires ; pour inclure aussi les fichiers binaires, il faut -uuu ; le plus gros problème de cette fonction, c’est qu’en l’utilisant sur le dépôt du noyau Linux, on obtient une erreur disant que la liste d’arguments est trop longue ; je l’ai donc remplacée par xargs
```
  $ git ls-files -z | time xargs -0 rg APM_RESUME
  ...

  real  0.638
  user  0.741
  sys   1.441
  maxmem 29 MB
  faults 0
  $ time rg APM_RESUME
  ...

  real  0.097
  user  0.399
  sys   0.588
  maxmem 29 MB
  faults 0
```
  Si quelqu’un a un exemple où git ls-files -z | xargs -0 rg ... est plus rapide qu’un simple rg ..., je veux bien le voir
- Après avoir écrit ce message, j’ai relu le manuel et j’ai découvert qu’au lieu de -uu, on peut utiliser le drapeau -. (recherche dans les fichiers cachés uniquement) ; ce serait bien de pouvoir chercher dans les fichiers cachés suivis par git, mais le surcoût généré par la requête de la liste des fichiers reste non négligeable, même si c’est écrit en Rust
- Peut-être que je rate quelque chose, mais ripgrep n’ignore-t-il pas déjà par défaut les fichiers non suivis par git ?
- Je me demande si cette méthode est plus rapide que git grep
J’utilise ripgrep tous les jours au travail, aussi bien en ligne de commande que pour les recherches dans vscode ; merci à burntsushi