Temps de lecture estimé : 6 minutes
Points clés à retenir
- Privilégier -r plutôt que -R pour éviter les boucles sur liens symboliques
- Limiter les patterns à 60 caractères max pour rester lisible
- Exclure node_modules et .git avec –exclude-dir avant toute recherche
- Ripgrep divise le temps d’exécution par 5 à 10 sur les gros dépôts
- Toujours tester un pattern en dry-run avant un remplacement en masse
Comprendre grep -r et le mode récursif
Le grep -r récursif est la première commande que j’apprends à tout développeur junior qui rejoint une équipe. En pratique, voilà ce que j’ai constaté : quand on doit fouiller un dépôt de plusieurs milliers de fichiers, l’option -r transforme une corvée en réflexe.
La syntaxe de base tient en une ligne : grep -r "motif" . parcourt le dossier courant et tous ses sous-dossiers. L’option -r (récursif, insensible aux liens symboliques par défaut) diffère de -R, qui suit les liens symboliques rencontrés. Ce détail change tout sur une arborescence profonde avec des liens vers d’autres dépôts.
Sur une arborescence à dix niveaux, grep descend sans limite tant que l’option n’est pas contrainte. Le comportement sur les liens symboliques mérite d’être testé avant un premier usage en production : un lien mal placé peut faire boucler la commande sur elle-même.
Exemples courts d’usage
Pour rechercher une chaîne simple dans tout un projet : grep -r "TODO" src/. On va pas se mentir, cette commande à elle seule remplace des heures de recherche manuelle dans un IDE mal configuré.
Quand utiliser -r versus d’autres options
La différence entre -r et -R se résume au suivi des liens symboliques. -R les suit systématiquement, ce qui peut faire remonter des résultats hors du périmètre attendu — ou provoquer une boucle infinie si deux liens se pointent mutuellement.
Pour un projet source classique, je préfère toujours -r. Quand j’étais en train de scaler la boîte, on a eu un incident bête : un lien symbolique vers node_modules avait fait exploser le temps d’exécution d’un script CI de 3 secondes à plus de 4 minutes.
Cas où -r est inefficace
Sur des fichiers binaires, grep -r perd du temps à scanner du contenu illisible. La commande signale généralement « binary file matches » sans intérêt réel. Le vrai sujet, c’est pas la technique, c’est de savoir quand exclure ces fichiers avant même de lancer la recherche.
Longueur optimale : patterns et expressions régulières
La longueur optimale d’un pattern grep -r récursif tient en une règle simple : rester lisible en ligne de commande. Je recommande des motifs de 60 caractères maximum pour garder une commande shell exploitable et débogable rapidement.
Mots entiers vs sous-chaînes
L’option -w force la correspondance sur des mots entiers. Sans elle, chercher « test » remonte aussi « testing », « contest » ou « latest » — un bruit qui pollue les résultats sur un gros dépôt.
Les expressions régulières simples suffisent dans 80 % des cas. grep -E ajoute la syntaxe étendue (alternance avec |, quantificateurs sans échappement) pour les cas plus fins, mais chaque niveau de complexité ajouté ralentit légèrement le parsing.
Optimiser un pattern pour éviter les faux positifs
Un pattern trop large comme grep -r "id" remonte des centaines de lignes inutiles. Ce que personne ne dit (et qui change tout) : ancrer le motif avec des délimiteurs précis (\bid\b ou -w) divise souvent le bruit par dix.
Performance et alternatives rapides
Sur un dépôt de 100 000 fichiers, grep -r met généralement entre 10 et 30 secondes, contre 1 à 5 secondes pour ripgrep (rg), selon les benchmarks publiés par le projet ripgrep lui-même. J’ai testé, j’ai raté, voilà ce qui fonctionne vraiment : sur un mono-repo de taille moyenne, ce gain change concrètement le confort de travail quotidien.
Limiter le scope
Trois options réduisent le périmètre de recherche : --include="*.js" cible une extension, --exclude="*.min.js" écarte les fichiers minifiés, --exclude-dir=node_modules saute les dossiers volumineux. Exclure node_modules et .git, souvent supérieurs à 100 Mo, accélère la recherche de façon immédiate.
Pour visualiser concrètement l’usage de grep sur des motifs et des lignes correspondantes, cette vidéo d’Adrien Linuxtricks détaille la syntaxe et les cas d’usage courants.
Alternatives : ripgrep et ack
Ripgrep est écrit en Rust et ignore par défaut les fichiers listés dans .gitignore, ce qui évite de fouiller node_modules sans configuration supplémentaire. Ack cible surtout le code source et reste plus lent que rg sur les gros volumes, mais garde une syntaxe proche de grep pour une transition en douceur.
Astuces pour gros dépôts
Sur un dépôt volumineux, les outils multithread comme rg peuvent diviser le temps d’exécution par 5 à 10, selon le système de fichiers et le disque utilisé. Éviter la lecture des fichiers binaires avec -I évite aussi du temps perdu.
| Critère | grep -r | ripgrep (rg) |
|---|---|---|
| Vitesse sur 100k fichiers | 10-30 s | 1-5 s |
| Respect .gitignore | Non par défaut | Oui par défaut |
| Disponibilité | Préinstallé partout | À installer |
| Syntaxe regex | POSIX (basic/extended) | Rust regex (proche PCRE) |
Exemples pratiques et recettes
Rechercher depuis la racine d’un dépôt avec numéro de ligne : grep -rn "motif" .. L’option -n affiche le numéro de ligne, indispensable pour naviguer directement vers le résultat dans un éditeur.
Rechercher plusieurs motifs
Deux approches : empiler des -e (grep -r -e "motif1" -e "motif2" .) ou passer par un fichier de motifs avec -f patterns.txt. La seconde option devient indispensable dès qu’on dépasse cinq ou six motifs à croiser.
Pipeliner avec sed, awk et xargs
grep -rl "motif" . | xargs sed -i 's/ancien/nouveau/g' combine recherche récursive et remplacement en masse. J’ai testé, j’ai raté, voilà ce qui fonctionne vraiment : toujours lancer d’abord sans -i pour vérifier la liste des fichiers concernés avant toute modification irréversible.
Pièges fréquents et bonnes pratiques
Les fichiers non-UTF-8 provoquent parfois des erreurs d’encodage silencieuses, où grep affiche des caractères corrompus au lieu du texte attendu. Forcer l’encodage avec LC_ALL=C avant la commande résout la majorité de ces cas.
Permissions et erreurs d’accès
Sur des dossiers protégés, grep -r remonte des erreurs « Permission denied » qui polluent la sortie. Combiner avec find . -perm permet de repérer en amont les fichiers inaccessibles plutôt que de les découvrir en cours de recherche.
Sauvegarder les résultats en CI
Dans un script CI, toujours rediriger la sortie de grep -r vers un fichier log horodaté. Un run qui échoue sans trace exploitable coûte plus de temps à diagnostiquer que la recherche elle-même.
Une recette CI simple : grep -rn "FIXME" src/ > fixme-report.txt || true. Le || true évite que le pipeline échoue si aucune correspondance n’est trouvée.
Checklist avant d’exécuter une recherche récursive
Avant de lancer un grep -r récursif sur un dépôt volumineux, je vérifie systématiquement quatre points : exclure node_modules et .git, ajouter -n pour les numéros de ligne, tester le pattern sur un sous-dossier avant le repo entier, et choisir ripgrep si le dépôt dépasse quelques dizaines de milliers de fichiers.
Pour un petit projet personnel, grep -r préinstallé suffit largement. Sur un mono-repo d’entreprise avec des dizaines de contributeurs, ripgrep s’impose par sa vitesse et son respect natif du .gitignore. Le bon sens entrepreneurial, c’est souvent aller à contre-courant : ne pas installer un outil supplémentaire tant que grep -r répond en dessous de la seconde sur votre usage réel.
