Effectivement, grep et ses alternatives peuvent être utiliser dans plusieurs contextes. Personnellement, je l'utilise principalement selon ses 3 formes :
Je travaille dans une base de code (disons, celle de LinuxFr.org), je suis le plus souvent à la racine du dépôt et je veux chercher un nom de fonction, de variable, un texte que je veux modifier, etc. dans les fichiers versionnés. Avec ripgrep, c'est facile, c'est rg foo. L'équivalent avec grep, ça doit être quelque chose comme grep -r --color --exclude log/ --exclude tmp/ --exclude uploads/ foo ..
Je cherche un motif dans un fichier ou répertoire donné (souvent pour retrouver un fichier config dans /etc dont je me rappelle une entrée mais pas le nom du fichier). Avec ripgrep, ça donne rg menu_entry /etc. Avec grep, c'est quasiment pareil : grep -r --color menu_entry /etc.
Enfin, je peux vouloir filtrer la sortie d'une ligne de commande. Avec ripgrep ou grep, pas vraiment de différence, cozy-stack instances ls | [rg|grep] _test | xargs cozy-stack instances rm.
J'ai pendant un temps eu un alias de grep pour faire grep -r --color=auto et avec ça, les cas d'usage 2 et 3 sont équivalents en termes de ligne de commande. Ripgrep est plus rapide, ça peut jouer un peu pour le cas d'usage 2. Je préfère la façon dont ripgrep affiche les résultats, mais les goûts et les couleurs, c'est très subjectif. Pour moi, la vraie différence est sur le cas d'usage 1 : c'est le besoin que je rencontre le plus souvent (je suis développeur) et ripgrep m'apporte un vrai confort. Même avec l'alias de grep, je suis obligé d'exclure les fichiers listés dans le gitignore et d'indiquer le répertoire dans lequel je veux chercher (ripgrep prend le répertoire courant par défaut). Ça m'est arrivé un paquet de fois de taper grep foo et d'attendre pendant plusieurs secondes bêtement pour juste me rendre compte que j'avais oublié de préciser de chercher dans le répertoire courant.
Cela dit que grep fasse cela par défaut serait gênant.
Je peux rater quelque chose, mais à mes yeux, ce n'est gênant que parce que grep existe depuis longtemps, qu'il a été utilisé de plein de manières différentes et que changer le comportement par défaut va casser certains scripts dans des cas particuliers difficiles à identifier à l'avance.
D'abord, parce que grep va perdre du temps à parcourir dans la hiérarchie même si on n'en a pas besoin;
Dans quel cas ça arriverait ? Dans les 3 cas d'usage ci-dessus, grep sans l'alias a cherché dans les mêmes fichiers et répertoires que grep avec l'alias pour ajouter l'option -r (ripgrep a cherché dans un peu moins de fichiers, parce que j'ai d'autres choses que juste tmp/ et log/ dans le .gitignore, mais c'était trop long de tout mettre sur la ligne de commande de grep).
ensuite, je combine souvent grep et find pour sélectionner les fichiers (ou plutôt leur type) à traiter.
Moi aussi, dans le cas d'usage 3, mais je n'ai jamais eu de problème que ce soit avec l'alias de grep ou avec ripgrep à ce sujet. Tu penses à quoi ?
[^] # Re: grep et find
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Des alternatives à grep, ls et find. Évalué à 5.
Effectivement, grep et ses alternatives peuvent être utiliser dans plusieurs contextes. Personnellement, je l'utilise principalement selon ses 3 formes :
Je travaille dans une base de code (disons, celle de LinuxFr.org), je suis le plus souvent à la racine du dépôt et je veux chercher un nom de fonction, de variable, un texte que je veux modifier, etc. dans les fichiers versionnés. Avec ripgrep, c'est facile, c'est
rg foo. L'équivalent avec grep, ça doit être quelque chose commegrep -r --color --exclude log/ --exclude tmp/ --exclude uploads/ foo ..Je cherche un motif dans un fichier ou répertoire donné (souvent pour retrouver un fichier config dans
/etcdont je me rappelle une entrée mais pas le nom du fichier). Avec ripgrep, ça donnerg menu_entry /etc. Avec grep, c'est quasiment pareil :grep -r --color menu_entry /etc.Enfin, je peux vouloir filtrer la sortie d'une ligne de commande. Avec ripgrep ou grep, pas vraiment de différence,
cozy-stack instances ls | [rg|grep] _test | xargs cozy-stack instances rm.J'ai pendant un temps eu un alias de grep pour faire
grep -r --color=autoet avec ça, les cas d'usage 2 et 3 sont équivalents en termes de ligne de commande. Ripgrep est plus rapide, ça peut jouer un peu pour le cas d'usage 2. Je préfère la façon dont ripgrep affiche les résultats, mais les goûts et les couleurs, c'est très subjectif. Pour moi, la vraie différence est sur le cas d'usage 1 : c'est le besoin que je rencontre le plus souvent (je suis développeur) et ripgrep m'apporte un vrai confort. Même avec l'alias de grep, je suis obligé d'exclure les fichiers listés dans le gitignore et d'indiquer le répertoire dans lequel je veux chercher (ripgrep prend le répertoire courant par défaut). Ça m'est arrivé un paquet de fois de tapergrep fooet d'attendre pendant plusieurs secondes bêtement pour juste me rendre compte que j'avais oublié de préciser de chercher dans le répertoire courant.Je peux rater quelque chose, mais à mes yeux, ce n'est gênant que parce que grep existe depuis longtemps, qu'il a été utilisé de plein de manières différentes et que changer le comportement par défaut va casser certains scripts dans des cas particuliers difficiles à identifier à l'avance.
Dans quel cas ça arriverait ? Dans les 3 cas d'usage ci-dessus, grep sans l'alias a cherché dans les mêmes fichiers et répertoires que grep avec l'alias pour ajouter l'option
-r(ripgrep a cherché dans un peu moins de fichiers, parce que j'ai d'autres choses que juste tmp/ et log/ dans le .gitignore, mais c'était trop long de tout mettre sur la ligne de commande de grep).Moi aussi, dans le cas d'usage 3, mais je n'ai jamais eu de problème que ce soit avec l'alias de grep ou avec ripgrep à ce sujet. Tu penses à quoi ?