ripgrep : chercher vite sans perdre les règles du dépôt

Filtrage `.gitignore` et recherche récursive

ripgrep, invoqué sous le nom `rg`, est un outil de recherche orienté lignes qui parcourt récursivement le répertoire courant pour trouver un motif regex. Son comportement par défaut est ce qui le distingue : il respecte les règles gitignore et ignore automatiquement les fichiers cachés, les répertoires cachés et les fichiers binaires. Le README indique que `rg -uuu` désactive tout ce filtrage automatique. Il positionne ripgrep comme similaire à The Silver Searcher, ack et grep, avec un support de premier ordre revendiqué pour Windows, macOS et Linux, et des téléchargements binaires précompilés pour chaque version. Le README ne définit pas ce qui compte comme fichier binaire, et aucune spécification séparée n'est donnée.

Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour ripgrep, le contrôle utile consiste à relier filtrage `.gitignore` et recherche récursive à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.

Types de fichiers, encodages et moteur PCRE2

Le README énumère de nombreuses voies d'installation plutôt qu'une seule méthode canonique. Des archives binaires précompilées sont disponibles pour Windows, macOS et Linux, les binaires Linux et Windows étant décrits comme des exécutables statiques. Les instructions pour gestionnaires de paquets couvrent Homebrew et Linuxbrew, MacPorts, Chocolatey, Scoop, Winget, Arch Linux, Gentoo, Fedora, openSUSE, EPEL pour CentOS Stream 10, Red Hat 10 et Rocky Linux 10, Nix, Flox, Guix, Debian et Ubuntu via apt ou un fichier .deb téléchargé, ALT, FreeBSD, OpenBSD, NetBSD, Haiku et Void Linux. Les programmeurs Rust peuvent utiliser `cargo install ripgrep`, et `cargo binstall` est proposé comme alternative. La version minimale de Rust prise en charge est 1.96.0, bien que ripgrep puisse fonctionner avec des versions plus anciennes. Le README note aussi que le binaire peut être plus gros que prévu car il contient volontairement des symboles de débogage ; `strip` peut réduire la taille.

Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour ripgrep, le contrôle utile consiste à relier types de fichiers, encodages et moteur pcre2 à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.

Benchmarks du noyau Linux et du fichier de 13 Go

Au-delà de la recherche de motif simple, ripgrep peut filtrer par type de fichier : `rg -tpy foo` limite une recherche aux fichiers Python, `rg -Tjs foo` exclut les fichiers JavaScript, et des règles de correspondance personnalisées peuvent apprendre de nouveaux types à ripgrep. Il prend en charge les lignes de contexte, les motifs multiples et le surlignage en couleur, et Unicode est toujours actif sans le ralentissement que le README attribue au mode Unicode de GNU grep. PCRE2 s'active via `-P/--pcre2` ou `--auto-hybrid-regex`, ce qui permet les assertions et les références arrière que le moteur regex par défaut ne prend pas en charge ; l'option `--engine` est une syntaxe alternative. Les autres fonctions documentées sont les remplacements, les encodages de texte autres que UTF-8 (UTF-16, latin-1, GBK, EUC-JP, Shift_JIS, entre autres) avec `-E/--encoding`, la recherche dans les fichiers compressés (brotli, bzip2, gzip, lz4, lzma, xz, zstandard) avec `-z/--search-zip`, des filtres de prétraitement d'entrée arbitraires et un fichier de configuration. Le README ne donne aucun détail sur la syntaxe du fichier de configuration au-delà d'un lien vers le guide.

Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour ripgrep, le contrôle utile consiste à relier benchmarks du noyau linux et du fichier de 13 go à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.

Choix Rust derrière le parcours parallèle

Le README présente plusieurs tableaux de benchmarks, tous exécutés sur un système avec un Intel i9-12900K à 5,2 GHz. Sur un arbre source du noyau Linux, `rg -n -w '[A-Z]+_SUSPEND'` a trouvé 536 lignes correspondantes en 0,082 s ; hypergrep a pris 0,167 s, git grep avec PCRE 0,273 s, The Silver Searcher 0,443 s, ugrep 0,639 s et ack 2,935 s en trouvant 2677 lignes. Dans un deuxième benchmark sur l'arbre du noyau avec le filtrage gitignore désactivé, `rg -uuu -tc -n -w '[A-Z]+_SUSPEND'` de ripgrep a terminé en 0,063 s contre 0,607 s pour ugrep et 0,674 s pour GNU grep. Sur un seul fichier décompressé d'environ 13 Go mis en cache en mémoire, `rg -w 'Sherlock [A-Z]\w+'` a pris 1,042 s, ugrep 1,339 s et GNU grep avec Unicode 6,577 s. Le README prévient qu'un seul benchmark ne suffit jamais et renvoie à un article de blog pour une analyse plus détaillée. Il montre aussi des chutes de performance : pour `rg '[A-Za-z]{30}'` sur le même fichier de 13 Go, ripgrep a pris 15,569 s, ugrep 21,857 s, GNU grep avec LC_ALL=C 32,409 s, tandis que GNU grep avec Unicode a pris 8 minutes 30 secondes. Les nombres de correspondances élevés réduisent les écarts, comme avec `rg the` qui a trouvé 83 499 915 lignes en 6,948 s contre 11,721 s pour ugrep et 15,217 s pour GNU grep.

Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour ripgrep, le contrôle utile consiste à relier choix rust derrière le parcours parallèle à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.

Quand `grep` reste le choix plus portable

Le README attribue la vitesse de ripgrep à des choix d'implémentation précis. Il est construit sur le moteur regex de Rust, qui utilise des automates finis, SIMD et des optimisations agressives de littéraux. Le décodage UTF-8 est intégré directement dans le moteur d'automate fini déterministe, c'est ainsi que le support Unicode reste rapide. La recherche fonctionne soit avec des mappages mémoire, soit de manière incrémentale via un tampon intermédiaire ; le README dit que ripgrep choisit automatiquement la meilleure stratégie, les mappages mémoire étant meilleurs pour les fichiers uniques et l'approche incrémentale pour les grands répertoires. Les motifs d'ignorance des fichiers .gitignore sont appliqués avec un RegexSet, donc un seul chemin de fichier peut être comparé à plusieurs motifs glob à la fois. Un itérateur de répertoire récursif parallèle sans verrou provient des crates crossbeam et ignore. Ce sont les explications du README ; cet article n'a aucun moyen indépendant de les vérifier.

Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour ripgrep, le contrôle utile consiste à relier quand `grep` reste le choix plus portable à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.

Compilation et tests avec Cargo

Le README liste des raisons de ne pas utiliser ripgrep, ce qui mérite d'être pris au sérieux. Si vous avez besoin d'un outil portable et omniprésent, ripgrep ne se conforme pas à POSIX ni à aucun autre standard, et grep reste le meilleur choix. S'il existe dans un autre outil une fonctionnalité ou un correctif de bug sur lequel vous comptez et qui n'est pas listé dans le README, c'est une raison de rester. Le README admet aussi qu'il existe des cas limites de performance où un autre outil fait mieux et demande des rapports de bug dans ces cas. Enfin, si ripgrep ne peut pas être installé sur votre machine ou n'est pas disponible pour votre plateforme, c'est une autre raison. Ce sont les avertissements déclarés par le projet lui-même, pas une évaluation indépendante.

Le dépôt doit être lu comme une documentation opératoire, pas comme une preuve de compatibilité universelle. Les détails retenus ici viennent du README et des fichiers de configuration indiqués par le projet. Lorsqu’une valeur n’est pas documentée, elle reste à vérifier dans un environnement isolé. Cette distinction est importante pour éviter de transformer une commande d’exemple en engagement de production. Les dépendances, les permissions et la version annoncée peuvent modifier le résultat obtenu. Pour ripgrep, le contrôle utile consiste à relier compilation et tests avec cargo à une sortie observable : journal, fichier produit, route appelée, certificat présenté ou état d’un service. Le dépôt ne fournit pas nécessairement toutes les garanties nécessaires à un usage sensible ; il faut documenter l’écart au lieu de le combler par une supposition.

Conclusion éditoriale

ripgrep convient à une équipe qui accepte ses dépendances et ses limites documentées ; il ne convient pas à un déploiement qui exige des garanties absentes du README. Avant adoption, exécutez le chemin propre à ce dépôt, vérifiez les fichiers et commandes cités dans l’article, puis contrôlez le résultat observable et les permissions associées.

Sources officielles

1. Official README
2. Project repository
3. Release notes