Bash étant turing complet tu vas bien finir par implémenter la gestion correcte de cette petite fonctionnalité. N'oublie pas que le .gitignore n'est pas forcément dans CWD il peut être plus haut (tu es dans un projet) ou bien plus bas et multiple (CWD ou ses fils contient plusieurs projets). Une fois que tu auras trouvé la solution tu pourras recopier ça à chaque fois que tu utilises grep. Ou alors tu mets ça dans un outils réutilisable que tu pipe mais alors ton appel standard à grep va toujours être un pipe de 3km de long alors tu vas faire un alias ou enrober ça dans un outil. Oh wait...
Ensuite tu passes aux fonctionnalités suivantes comme les globing pattern, la recherche dans les fichiers compressés, la recherche multi-threadée, la gestion d'encoding .
Dans une vue ops d'intervention se limiter aux outils standards est cohérent (standard pouvant varier selon les environnements on peut aller jusqu'à strictement POSIX). Les outils dont on parle sont eux parfaitement adaptés aux problématiques dev. Leur comportement par défaut correspond souvent à ce que l'on veut et les cas d'utilisations courants sont couverts avec quelques options simples plutôt que des kilomètres de pipe à base de sed | cut | awk | parallel | grep -v | variables d'environnement obscures.
Et on peut facilement maitriser les deux monde si on évolue dans les deux mondes.
[^] # Re: J'aime pas les "alternatives"
Posté par ckyl . En réponse à la dépêche Des alternatives à grep, ls et find. Évalué à 7.
Non. Voir https://git-scm.com/docs/gitignore -> Pattern format.
Bash étant turing complet tu vas bien finir par implémenter la gestion correcte de cette petite fonctionnalité. N'oublie pas que le .gitignore n'est pas forcément dans CWD il peut être plus haut (tu es dans un projet) ou bien plus bas et multiple (CWD ou ses fils contient plusieurs projets). Une fois que tu auras trouvé la solution tu pourras recopier ça à chaque fois que tu utilises grep. Ou alors tu mets ça dans un outils réutilisable que tu pipe mais alors ton appel standard à grep va toujours être un pipe de 3km de long alors tu vas faire un alias ou enrober ça dans un outil. Oh wait...
Ensuite tu passes aux fonctionnalités suivantes comme les globing pattern, la recherche dans les fichiers compressés, la recherche multi-threadée, la gestion d'encoding .
Dans une vue ops d'intervention se limiter aux outils standards est cohérent (standard pouvant varier selon les environnements on peut aller jusqu'à strictement POSIX). Les outils dont on parle sont eux parfaitement adaptés aux problématiques dev. Leur comportement par défaut correspond souvent à ce que l'on veut et les cas d'utilisations courants sont couverts avec quelques options simples plutôt que des kilomètres de pipe à base de sed | cut | awk | parallel | grep -v | variables d'environnement obscures.
Et on peut facilement maitriser les deux monde si on évolue dans les deux mondes.