ack 1.96 — mieux que grep

Posté par  (site web personnel) . Modéré par Xavier Teyssier. Licence CC By‑SA.
Étiquettes :
48
20
sept.
2011
Ligne de commande

Ack est un outil qui permet de rechercher du texte à l’intérieur de fichiers. C’est donc un clone de grep avec quelques améliorations notables. Voici donc dix raisons de passer à ack si vous utilisez grep :

  1. ack est très rapide, car il ne recherche que ce que vous voulez chercher ;
  2. il recherche récursivement par défaut ;
  3. il ignore les trucs inutiles, comme les répertoires utilisés par les [VCS], les fichiers de sauvegarde (« foo~ » et « #foo# »), les binaires, etc. ;
  4. vous pouvez spécifier simplement le type de fichiers à rechercher, comme « --perl » ou « --nohtml » ;
  5. la coloration syntaxique des résultats est là par défaut ;
  6. vous pouvez utiliser les expressions régulières de Perl, pas juste le sous‐ensemble de GNU ;
  7. l’apprentissage d’ack est très simple, car il reprend les mêmes options en ligne de commande que grep (« -c », « -l », « -w », etc.) ;
  8. il est possible d’avoir des options par défaut dans un fichier « ~/.ackrc » ;
  9. la commande fait 25 % de caractères en moins à taper ;
  10. en fait, c’est même 50 % de gagné par rapport à « grep -r ».

La version 1.96 d’ack est sortie dimanche et apporte quelques améliorations notables :

  • les fichiers JavaScript « minifiés » sont ignorés par défaut ;
  • le langage Groovy est supporté (extensions : « .groovy », « .gtmpl », « .gpp », « .grunit ») ;
  • les fichiers Perl et Lua sont mieux détectés.

Note : pour installer ack sur Debian et Ubuntu, il faut faire un « apt-get install ack-grep » (et pas juste « ack »). En revanche sous Archlinux, un « pacman -S ack » sera suffisant. Les autres distributions (Fedora, Gentoo) utilisent également le simple nom « ack »).

Aller plus loin

  • # Commande

    Posté par  . Évalué à 4.

    1. la commande fait 25 % de caractères en moins à taper ;
    2. en fait, c’est même 50 % de gagné par rapport à « grep -r ».

    Je ne suis pas d'accord, ack, c'est 200% de caractères en plus. Peut-être est-ce dû à mon 'alias g="grep -r"'. (et aussi grâce à zsh, avec 'alias -g PG=" | grep "')

    • [^] # Re: Commande

      Posté par  . Évalué à 4.

      en fait, c’est même 50 % de gagné par rapport à « grep -r ».

      J'aurais plutôt contesté le 50% étant donné que « ack » fait 3 caractères, là où « grep -r » en fait 7 (l'espace aussi est à saisir)...
      Après, on peut encore plus s'adonner aux joies de la drosophilie, grâce à la complétion des commandes (touche Tab), ce qui peut fait gagner quelques caractères.

      • [^] # Re: Commande

        Posté par  . Évalué à 4.

        Ou en perdre, si "tab" indique une incertitude, puis une autre, puis ... :)

    • [^] # Re: Commande

      Posté par  . Évalué à 2.

      Sans parler du fait que A C K sont éloignées sur le clavier alors que G R E se tapent en une seule fois (même avec la tête on y arrive).
      Et avec un alias g="grep -r --color" on fait tomber un argument de plus...
      ;-)

      • [^] # Re: Commande

        Posté par  . Évalué à 2.

        Si on tape avec 2 doigts c'est vrai, avec 10 doigts ack se tape avec "auriculaire gauche", "index gauche", "majeur droit", ce qui est plus facile sur un clavier azerty (on alterne les doigts) que "index gauche", "index gauche", "majeur gauche", "annulaire droit" ;)

        Étienne

        • [^] # Re: Commande

          Posté par  . Évalué à -1.

          Avec seulement 5 doigts : 'g' (index gauche), 'r' (majeur gauche), 'e' (annulaire gauche) <tab> (auriculaire gauche) pour avoir le 'p' puis <espace> (pouce gauche).

          C'est pas orthodoxe mais ça a un certain esthétisme et ça fait travailler tous les doigts 0:-°

          • [^] # Re: Commande

            Posté par  . Évalué à 0.

            L'espace est ajouté automatiquement chez moi avec le (debian), donc 4 doigts :p

    • [^] # Re: Commande

      Posté par  . Évalué à 2.

      Sous Debian, 'ack' ne fonctionne pas. Il faut taper 'ack-grep'.
      Donc c'est plus long que 'grep -r'.

      • [^] # Re: Commande

        Posté par  (site web personnel) . Évalué à 4.

        Le site d'ack donne la commande suivante pour l'installer en tant que ack :

        sudo dpkg-divert --local --divert /usr/bin/ack --rename --add /usr/bin/ack-grep

  • # Il fallait y penser

    Posté par  (site web personnel) . Évalué à 7.

    C'est vrai qu'on a tellement (enfin « je », je vous laisse exprimer votre opinion vous-mêmes) tendance à mettre sur un piedestal ces petits outils GNU, qu'on oublierait presque leurs imperfections. En tout cas, on s'accoutume à leurs lacunes et jamais je n'oserai aller voir ailleurs.

    Heu, tant qu'on y est, vous n'auriez pas un remplaçant pour find qui soit plus simple à utiliser avec les fichiers avec espaces ? Ha, on me souffle dans l'oreillette que bash c'est bien gentil, mais une vrai plateforme de script c'est quand même plus pratique. Ok, ipython, c'est sympa, mais bash et ses petits copains sont tellement plus concis, rapide, ancrée dans notre culture ancestrale, toussa …

    Ce commentaire est terminé, il faut que j'aille voir ce ack de plus près.
    Merci pour la dépêche.

    • [^] # Re: Il fallait y penser

      Posté par  (site web personnel) . Évalué à 8.

      vous n'auriez pas un remplaçant pour find qui soit plus simple à utiliser avec les fichiers avec espaces ?

      ZSH supporte depuis longtemps le wildcard ** qui permet de faire des choses comme

      rm -f **/*~
for f in **/*.c; do commande $f; done

      qui marchent nickel avec des espaces, évitent de créer un processus supplémentaire, et répondent à la plupart des besoins courants.

      La bonne nouvelle, c'est que bash a la même chose maintenant (depuis la 4.0 je crois), si on utilise « shopt -s globstar ».

      • [^] # Re: Il fallait y penser

        Posté par  (site web personnel) . Évalué à 8.

        en zsh il y a encore plus simple:
        zargs **/*.c -- commande

        tu peux aussi choisir le nombre de processus en parallèle:
        --max-procs=max-procs, -P max-procs
        le nombre d'arguments à filer à la commande:
        --max-args=max-args, -n max-args
        et beaucoup plus
        Un super xargs quoi mais tu peux le combiner avec les fonctionalités avancées de zsh donc top
        pour en bénéficié: autoload -U zargs dans le .zshrc :)

    • [^] # Re: Il fallait y penser

      Posté par  . Évalué à 10.

      vous n'auriez pas un remplaçant pour find qui soit plus simple à utiliser avec les fichiers avec espaces ?

      Je te conseille xargs, très bon complément à find et à nombre d'outils GNU (j'apprécie en particulier la possibilité de lancer des commandes en parallèle).

      Petit exemple pour extraire toutes les archives ZIP sans se soucier des noms, et pour deux archives en même temps :

      $ find -name '*zip' -print0 | xargs -0 -I {} -n 1 -P 2 7z x {}

      La manpage de xargs a changé ma vie.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Il fallait y penser

        Posté par  (site web personnel) . Évalué à 10.

        xargs -0 -I {} -n 1 -P 2 7z x {}

        Et moi qui croyait qu'on cherchait à avoir un outil simple à utiliser...

        • [^] # Re: Il fallait y penser

          Posté par  . Évalué à 9.

          Oui bon, j'ai tellement l'habitude que ça me paraît excessivement simple, mais je dois confondre avec « concis » :-)

          Petite explication de texte :

          • -0 : pour lire les noms séparés par des \0 (pour correspondre au -print0 de find) et ne pas se soucier des caractères hors-normes ;
          • -I {} : l'expression qui représente les noms des fichiers dans la commande qu'on va lancer ;
          • -n 1 : on lance la commande une fois par fichier ;
          • -P 2 : le nombre de commandes lancées simultanément ;
          • 7z x {} : la commande elle-même, avec les fichiers.

          N'empêche qu'après avoir lu la doc, c'est tout de même relativement simple (en tout cas plus que des boucles ou d'autres structures à faire en shell)

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Il fallait y penser

          Posté par  . Évalué à 2.

          J'oublais : la demande était « remplaçant pour find qui soit plus simple à utiliser avec les fichiers avec espaces ».

          De ce point de vue, quand on voit comment find est ch*ant avec les noms à espace, c'est bel et bien plus simple :-)

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Il fallait y penser

            Posté par  . Évalué à 4.

            De mémoire, il y a aussi une commande exec sur le find.

          • [^] # Re: Il fallait y penser

            Posté par  . Évalué à 4.

            en même temps les 3/4 de sa commande sont inutile :

            $ find -name '*zip' -print0 | xargs -0 -n 1 7z x

            sachant que si tu limite à un seul argument il vaut mieux utiliser le -exec de find; le -P 2 sert à préciser le nombre de processus et tu peux avoir des alias pour couvrir les cas courants.

            $ find -name '*zip' -exec 7z x {}\;

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: Il fallait y penser

              Posté par  . Évalué à 2.

              le -P 2 sert à préciser le nombre de processus et tu peux avoir des alias pour couvrir les cas courants.

              C'est malheureusement un truc que find ne fait pas tout seul (lancer les exec sans attendre leur retour), peut être que ça peut s'obtenir comme ça :

              $ find -name '*zip' -exec 7z x {} \& \;

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Il fallait y penser

            Posté par  . Évalué à 2.

            En quoi c'est chiant les noms de fichier avec des espaces pour find ?

            Il ne suffit pas d'utiliser des guillemets pour ne pas être emmerdé ?

            • [^] # Re: Il fallait y penser

              Posté par  . Évalué à 1.

              Les guillemets n'avancent à rien

              $ commande $(find /dir)
              -> Problème avec les espaces

              $ commande "$(find /dir)"
              -> Encore pire, concatène tous les noms de fichiers en un seul

              $ find /dir|xargs commande
              -> Problème avec les retours charriot dans les noms de fichiers. Il faut être fou pour en mettre, mais un BON outil doit gérer.

              $ find /dir -print0|xargs -0 commande
              -> Gère correctement tous les noms de fichiers.

              • [^] # Re: Il fallait y penser

                Posté par  . Évalué à 1.

                $ find /dir|xargs commande
                -> Problème avec les retours charriot dans les noms de fichiers.

                Si /dir contient un très grand nombre de fichiers, tu auras surtout « line too long » pour ta commande, à moins d’utiliser l’option -n nombre_d_arguments de xargs pour lancer une commande tous les nombre_d_arguments.

                $ find /dir -print0|xargs -0 commande
                -> Gère correctement tous les noms de fichiers.

                Et tu n’as jamais de « line too long » ?

                Pour ma part, j’utilise gnéralement
                $ find /dir -exec commande {} \;

                Je n’ai jamais eu de problème avec.
                Cela dit, ça lance une commande par fichier, mais tu peux placer l’argument où tu veux dans la commande, voire le répéter (avec le find de GNU, tous ne le supportent pas) ; par exemple :
                $ find . -type f -exec cmp {} /backup_du_repertoire_courant/{} \;
                (faire attention au répertoire de base choisi : ça ne préviendra pas s’il manque un fichier dans le répertoire courant par rapport à /backup_du_repertoire_courant).

                « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                • [^] # Re: Il fallait y penser

                  Posté par  . Évalué à 0.

                  Et tu n’as jamais de « line too long » ?

                  Non, je n'ai jamais ça. Par défaut xargs découpe automatiquement la ligne en plusieurs si elle est trop longue.
                  Par contre, ça peut avoir une importance pour les commandes qui ne traitent pas tous leur paramètres de la même manière.

                  $ find /dir -exec commande {} \;

                  En effet, ça marche très bien.
                  L'objectif de mon commentaire était juste de montrer que les guillemets ne résolvent pas les problèmes d'espace, rien de plus.

    • [^] # Re: Il fallait y penser

      Posté par  . Évalué à 4.

      ces petits outils GNU

      Attention! grep n'est pas forcément GNU, c'est POSIX.2, et il est tout à fait possible de forcer le comportement a du posix.2 via la variable POSIXLY_CORRECT. Il est aussi possible d'avoir des options par défaut via la variable GREP_OPTIONS, et une bonne partie des options par défaut de ack sont possible (--exclude=PATTERN... --include=PATTERN...)

      L'avantage de scripter avec les commandes posix, c'est que c'est portable ensuite sur n'importe quel environnement posix, et que via des alias on peut via un fichier de conf récupérer tout ce qu'on aime. )

      L'inconvénient est de figer les possibilité à ce que permet la norme.

      pour find et xargs généralement j'utilise
      find . -print0 ... | xargs -0 ...

      Ou plus généralement des fonctions bash (find0) et un alias xarg0 qui me mettent les paramètres comme il faut ;) j'ai pas encore trouver comment faire des alias avec des mélanges de paramètres .

      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # Argument

    Posté par  (site web personnel) . Évalué à 10. 

    ack est très rapide, car il ne recherche que ce que vous voulez chercher ;

    C'est pas un argument ça...

    J'en déduit que les concurrents ne recherchent pas ce que je veux ?

    Et Omo ? il lave plus blanc que blanc ?

    • [^] # Re: Argument

      Posté par  . Évalué à 6.

      J'ai été moyen convaincu par l'argument, donc j'ai comparé avec un gros répertoire de dev plein de .svn :

      dev_folder> for i in 1 2 3 4 5 6 ; do
for> time grep -R ioctl . > /dev/null
for> time ack ioctl . > /dev/null
for> done

      Résultat triés :
      grep  0.79s user 1.11s system 2% cpu  1:31.60  total
grep  0.77s user 0.97s system 2% cpu  1:13.71  total
grep  0.81s user 1.04s system 2% cpu  1:11.72  total
grep  0.79s user 1.00s system 2% cpu  1:08.15  total
grep  0.81s user 0.98s system 2% cpu  1:07.35  total
grep  0.80s user 1.04s system 2% cpu  1:07.79  total
ack   2.99s user 0.37s system 12% cpu   26.835 total
ack   2.83s user 0.21s system 38% cpu    7.835 total
ack   2.88s user 0.36s system 14% cpu   23.123 total
ack   2.84s user 0.26s system 31% cpu    9.906 total
ack   2.76s user 0.30s system 15% cpu   19.258 total
ack   2.79s user 0.26s system 32% cpu    9.388 total

      Y a pas à chier, pour mon utilisation habituelle, ack est bien plus rapide. Je ne connaissais pas, merci!

      • [^] # Re: Argument

        Posté par  . Évalué à 1.

        Et avec "export LC_ALL=C", ça donne quoi ? (en recherche 8bits le GNU grep est vraiment très très bon...)

        • [^] # Re: Argument

          Posté par  . Évalué à 2.

          Globalement, même résultats, just ack qui est un peu plus lent.

      • [^] # Re: Argument

        Posté par  (site web personnel) . Évalué à 2.

        Surprenant. Chez moi, grep pulvérise ack complètement:

        ==> time ack print . > /dev/null
        ack print . > /dev/null 16.86s user 2.63s system 33% cpu 59.020 total
        ==> time grep print -r . > /dev/null
        grep --color=auto print -r . > /dev/null 0.82s user 1.88s system 8% cpu 30.275 total
        ==> time ack print . > /dev/null
        ack print . > /dev/null 9.02s user 0.53s system 99% cpu 9.576 total
        ==> time grep print -r . > /dev/null
        grep --color=auto print -r . > /dev/null 0.43s user 0.35s system 97% cpu 0.797 total
        ==> time ack print . > /dev/null
        ack print . > /dev/null 9.20s user 0.51s system 99% cpu 9.746 total
        ==> time grep print -r . > /dev/null
        grep --color=auto print -r . > /dev/null 0.41s user 0.32s system 97% cpu 0.748 total

        (tout dans le même répertoire, les deux premières commandes sont visiblement plus lentes à cause des accès disques, les suivantes trouvent tout dans les caches)

      • [^] # Re: Argument

        Posté par  (site web personnel) . Évalué à 1.

        € echo $GREPOPTIONS --color=auto --exclude=..swp --exclude=__* --exclude=.del-* --exclude=tags --exclude=.svn Pas besoin de passer à ack.

        • [^] # Re: Argument

          Posté par  . Évalué à 2.

          Même résultats... j'ai aussi essayé -I, pas de grosses différences. J'avoue être assez intrigué par la raison de cette différence entre ack et grep, alors qu'avec les bonnes options grep devrait être plus rapide.

          • [^] # Re: Argument

            Posté par  . Évalué à 3.

            Je pense que la grosse différence c'est que ack ne scanne que les fichiers qu'il connait, par exemple il ne scanne pas les fichiers sans extension. Sur ma machine quand je lance ack dans /etc il me scanne 381 fichiers (1981 avec un ack -a qui continue à en louper plein) là où grep m'en scanne 7535.

            C'est d'ailleurs un des pièges de ack qui, rappelons le, n'est pas un outil généraliste, on peut passer à côté de fichiers qu'il ne scanne pas sans s'en rendre compte.

            Étienne

            • [^] # Re: Argument

              Posté par  . Évalué à 1.

              Si avec le -a, on loupe des trucs, je trouve cela inquiétant ...

              • [^] # Re: Argument

                Posté par  . Évalué à 1.

                Je pense qu'il faut utiliser -u

                File inclusion/exclusion:
  -a, --all-types       All file types searched;
                        Ignores CVS, .svn and other ignored directories
  -u, --unrestricted    All files and directories searched

  • # C'est différent de grep

    Posté par  . Évalué à 10.

    Dire que ack est mieux que grep c'est comme dire que la carte au 25000ème est mieux que la carte au 500000ème, c'est vrai pour la randonnée, pas pour traverser une région. Ack est un outil plus spécialisé que grep et pour une activité de codage est plus adapté que grep (comme rappelé, le fait qu'il ignore les répertoires de VCS ou les fichiers de sauvegarde, qu'il connaisse les types de fichiers et permette de filtrer dessus).

    Si on veux faire un grep dans tout /etc par exemple, grep sera plus rapide que ack (le point 1 de la dépêche veut en fait dire : "ack est plus lent que grep pour le matching mais il compense en ne cherchant pas dans tous les fichiers", c'est intéressant si on ne veut pas chercher dans tous les fichiers).

    Voilà c'était juste pour tempérer la remarque "mieux que grep", je l'utilise personnellement en remplacement de grep pour mes activités de codage, mais je n'ai pas pour autant remisé grep au placard.

    Sinon merci pour la dépêche, ack mérite d'être un peu plus connu.

    Étienne

  • # git grep

    Posté par  (site web personnel) . Évalué à 8.

    En fait, la plupart des ces arguments s'appliquent aussi à « git grep » (pour peu qu'on utilise Git, mais franchement, qui utiliserait autre chose de nos jours ;-) ) :

    1. Il ne cherche que dans les sources (i.e. dans ce qui est référencé par l'index de Git), donc ni dans les *~, ni dans les *.o, ni dans le .git par défaut
    2. La mise en couleur des résultats est là par défaut si on a color.ui=true dans ~/.gitconfig.
    3. Pour le nombre de caractères à taper, cf. ci-dessus, les alias c'est fait pour ça ;-).

    Ceci dit, y'a l'air d'y avoir des trucs rigolos dans ack, comme le --perl qui regarde le shebang du fichier pour savoir si c'est du perl, ou

    ack --cc '#include\s+<(.*)>' --output '$1' -h

    qui fait grosso-modo un
    grep ... | sed 's/.../.../'

    • [^] # Re: git grep

      Posté par  . Évalué à 4.

      (pour peu qu'on utilise Git, mais franchement, qui utiliserait autre chose de nos jours ;-) )

      La bonne question est plutôt de savoir qui n'utilise pas un (D)VCS de nos jours ? La réponse est : lui !

    • [^] # Re: git grep

      Posté par  (site web personnel) . Évalué à 3.

      qui fait grosso-modo un

      grep ... | sed 's/.../.../'

      qui fait grosso modo un

      sed '/…/s/…/…/'

    • [^] # RCS, sinon quoi ?

      Posté par  . Évalué à 1.

      (pour peu qu'on utilise Git, mais franchement, qui utiliserait autre chose de nos jours ;-) )

      J’utilise RCS (qu’est-ce que j’ai gagné ?).
      Bon, c’est pour versionner les fichiers de configuration du système en étant sûr de pouvoir y accéder dans les conditions les plus hostiles : pas de réseau, système complètement HS (donc accès depuis un autre système ou un Live CD).

      Si quelqu’un connaît un DVCS qui peut supporter de telles conditions, ça peut m’intéresser...

      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

      • [^] # Re: RCS, sinon quoi ?

        Posté par  . Évalué à 7.

        Ben, c'est possible avec tous, puisque justement dans un DVCS tu a une copie locale complète du repository.
        Et si tu n'a pas besoin de recentraliser, ça se fait aussi bien avec CVS ou subversion, il suffit d'avoir le repository dans un répertoire à côté et d'y accéder directement en fichier sans passer par un protocol réseau.

        • [^] # Re: RCS, sinon quoi ?

          Posté par  . Évalué à 1.

          Ben, c'est possible avec tous, puisque justement dans un DVCS tu a une copie locale complète du repository.

          Bonne remarque, merci.

          Autre question : y a-t-il des DVCS qui soient capables de restaurer les fichiers avec leurs permissions, propriétaires, voire ACL ?

          Quand à CVS et Subversion, mon but était justement de sauter cette étape en attendant que les DVCS soient suffisamment mûrs. Mon problème, maintenant, c’est d’en choisir un. Darcs a l’air plus souple que les autres dans certaines situations, Mercurial a l’air plus facile à utiliser, Git est le plus utilisé (et peut-être plus performant que les deux autres, mais ce n’est pas très important pour ce que j’ai a en faire).

          « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

          • [^] # Re: RCS, sinon quoi ?

            Posté par  . Évalué à 4.

            Pour ton cas d'utilisation, je recommande chaudement etckeeper (http://kitenet.net/~joey/code/etckeeper/) combiné avec git.

            Très bien fichu, etckeeper s'occupe de tout les détails spécifique au versionning de /etc de façon automatique et bien pensée. Il n'oublira pas par exemple de :

            • Stocker (dans un fichier versionné aussi) et restorer (si besoin) les droits et propriétaires
            • Se hooker automatiquement sur le gestionnaire de paquets et commiter automatiquement avant et après les installes et upgrades (pratique pour repérer très préciséments les modifs liées à une upgrade).
            • Ajoute automatiquement dans un .gitignore les fichiers générés/dynamiques de /etc qui n'ont pas a être versionnés (comme /etc/mtab par ex), ce qui limite le bruit dans l'historique
            • Compenser les limitations des principaux SCM (par ex. Darcs ne gère pas les symlinks, ne conserve pas les droits d'execution, etc., mais etckeeper le fera pour lui), fait en sorte que les répertoires vides soient aussi versionnés, etc.
            • Réduire les droits du /etc/.git au mode 0700 pour des raisons de sécurité
            • ...

            Concernant ta question, la doc d'etckeeper indique par exemple :
            > "Among other chores, etckeeper init sets up a pre-commit hook that stores metadata about file owners and permissions into a /etc/.metadata file. This metadata is stored in version control along with everything else, and can be applied if the repo should need to be checked back out."

          • [^] # Re: RCS, sinon quoi ?

            Posté par  . Évalué à 3.

            Pour les ACL je ne sais pas, mais les permissions et propriétaire Git sait faire.

            La preuve, c'est que lorsque tu les modifies (sans toucher au contenu), un git status te l'affiche et tu peux le commiter.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: RCS, sinon quoi ?

              Posté par  (site web personnel) . Évalué à 2.

              les permissions et propriétaire Git sait faire.

              ???

              Git ne gère que le bit « executable ». Le format de stockage permettrait de stocker les bits r et w, mais en pratique, il n'utilise que les modes 755 et 644, puisque c'était plutôt contre-productif de gérer r et w dans un outil prévu pour gérer des sources (je crois que les toutes premières versions le faisaient, et ça a été supprimé).

              Le propriétaire, là, je demande à voir, y'a rien qui permette de stocker ça dans les structures « tree » de Git.

  • # Merci

    Posté par  . Évalué à 1.

    La lecture de ce journal m'a fait prendre conscience que j'en avais un peu marre des inconvénients de grep (le fait qu'il fouille automatiquement dans les fichiers des VCS / DVCS principalement), j'ai donc sauté sur cet outil. Très facile à installer :

    curl http://betterthangrep.com/ack-standalone > ~/bin/ack && chmod 0755 !#:3

    Petite question tant qu'on y est, comment peut-t-on configurer le bouzin pour qu'il n'ignore pas les fichiers de backup ?

    Encore merci du tuyau,

  • # Intérêt ?

    Posté par  . Évalué à 3.

    Personnellement je ne vois pas vraiment les avantages listés comme des choses décisives, et après pour les options que j'utilise souvent il y a toujours les alias donc bon ...

    Mais après si je n'en ressens aucunement le besoin c'est que je ne dois pas utiliser grep suffisamment (n'étant pas admin système) !

  • # Hum

    Posté par  (site web personnel, Mastodon) . Évalué à -1. 

    $sudo apt-get install ack
$man ack

    Me donne 

    ack - Kanji code converter

    Visiblement il y a une collision dans le nom du programme sur ubuntu ;)

    J'ai plus qu'une balle

    • [^] # Re: Hum

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Il suffisait d'aller faire un petit tour sur le site, pour savoir que le packet s'appel :
      ack-grep

      ;)

      J'ai plus qu'une balle

    • [^] # Re: Hum

      Posté par  (site web personnel) . Évalué à 8.

      Relis la dépêche. Relis en particulier la petite note qu'en Gentil Modérateur (GM) a pris la peine d'ajouter.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: Hum

      Posté par  (site web personnel) . Évalué à 1.

      Visiblement il y a une collision dans le nom du programme sur ubuntu ;)

      ack-grep sous debian

    • [^] # Re: Hum

      Posté par  . Évalué à 0.

      D'où, sans doute, la raison du nom "ack-grep". Faut croire que les empaqueteurs n'ont pas fait le travail jusqu'au bout...

      • [^] # Re: Hum

        Posté par  (site web personnel) . Évalué à 3. 

        Package: ack
Priority: extra
Section: text
Installed-Size: 96
Maintainer: Masayuki Hatta (mhatta) <mhatta@debian.org>
Architecture: amd64
Version: 1.39-12
Depends: libc6 (>= 2.7-1)
Filename: pool/main/a/ack/ack_1.39-12_amd64.deb
Size: 18910
MD5sum: f4120b7d5a274c6a876830215099552a
SHA1: efce296cd65d8907a0f3c4aa85b892776357dd61
SHA256: 0a5f7fb1d97b163ff2ed47be4a5e33f0af8b0bf7ff3e43e7b0c8e2e661664baf
Description: Kanji code converter
 ACK is a highly versatile Kanji code checker/converter.  ACK can do
 reciprocal conversion among Japanese EUC, Shift-JIS and 7bit JIS.
 JIS Kata-kana(SJIS Han-kaku Kana) is also supported.  Kanji code can
 be automatically detected even if the input stream contains Kata-kana
 characters.  Besides, ACK can be used as a Kanji code checker with
 very high detection rate.
Tag: culture::japanese, interface::commandline, role::program, scope::utility, use::converting, works-with::text

        Le paquet existant avant le ack en perl, ils l'ont nommé ack-grep ! Le choix n'est jamais facile à faire.

  • # remplaçant de glimpse ?

    Posté par  (site web personnel) . Évalué à 1.

    Tant qu'on est dans la problématique grep, il n'existe pas AMHO d'équivalent open source du fantastique glimpse qu'on arrive toujours à trouver tant bien que mal sur le Web. L'utilisation de glimpse commence par glimpseindex qui va parcourir les répertoires spécifiés pour stocker tous les mots dans des fichiers et ensuite, la commande glimpse, avec des expressions régulières, permet de retrouver instantanément les occurrences des chaines de caractères. C'est ultra-pratique, pour ne pas dire indispensable, quand on travaille sur un très gros logiciel.

    • [^] # Re: remplaçant de glimpse ?

      Posté par  (site web personnel) . Évalué à 3.

      C'est un genre de cscope ?

      "La première sécurité est la liberté"

    • [^] # Re: remplaçant de glimpse ?

      Posté par  . Évalué à 1.

      il existe aussi les id-utils, c'est une sorte d'indexer plutôt penser
      pour les fichiers sources. On fait un mkid dans un répertoires, il visite
      tous les sous répertoires et fait une base nommée ID par défaut. Ensuite on
      fait des recherches avec lid . Les id-utils sont plus faits pour les fichiers sources mais pas seulement.

  • # Similaire à glark ?

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    J'avais découvert et testé recemment glark, qui ressemble beaucoup à ack. Quelqu'un connait les différences entre les deux (hormis le fait que glark soit écrit en ruby et ack en perl) ?

    http://www.incava.org/projects/glark

    WeeChat, the extensible chat client

  • # Alternatives

    Posté par  (site web personnel) . Évalué à 2.

    Il est vrai que nous avons tendances à ignorer les alternatives aux outils Unix classiques (ou aux dérivés de chez GNU).

    Ce qui me fait poser la question suivante : existe-t-il une liste à jour d'outils alternatifs à ces classiques ? (find, grep, head etc.)

    • [^] # Re: Alternatives

      Posté par  (site web personnel) . Évalué à 6.

      existe-t-il une liste à jour d'outils alternatifs à ces classiques ? (find, grep, head etc.)

      Emacs ?

    • [^] # Re: Alternatives

      Posté par  (site web personnel) . Évalué à 4.

      Il est vrai que nous avons tendances à ignorer les alternatives aux outils Unix classiques

      Pour un raison simple, tu n'est pas tjs admin de la machine sur laquelle tu bosses, alors autant prendre l'habitude d'utiliser des outils que tu trouves partout et pas te manger des "command not found" .

      • [^] # Re: Alternatives

        Posté par  (site web personnel) . Évalué à 2.

        Certes, mais ça ne répond pas à la question.

        Quand je suis admin de ma machine, j'ai le droit d'installer les logiciels qu'un tier ne voudrait pas non ?

    • [^] # Re: Alternatives

      Posté par  . Évalué à 3.

      Ce qui me fait poser la question suivante : existe-t-il une liste à jour d'outils alternatifs à ces classiques ? (find, grep, head etc.)

      J'utilise zsh en login shell depuis quelques années et je suis encore loin d'utiliser toutes ses possibilités. Un exemple que j'aime bien c'est ce script par exemple qui ne fait aucun appel aux classiques grep/sed/awk/… :
      http://pastebin.com/A2d4Js5W

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Autres commandes du même type

    Posté par  (site web personnel) . Évalué à 4.

    Il existe des clones de cette commande en python et en ruby :
    rak pour ruby et grin pour python

    Ces deux programmes ont globalement la même fonction. Perso j'utilise grin

    • [^] # Re: Autres commandes du même type

      Posté par  . Évalué à 5.

      C'est beau.

      Il me manquait une ou deux fonctionnalités dans l'outil, j'ai donc décidé de le ré-écrire.

      Ce qui est bien avec le libre, c'est de pouvoir travailler en collaboration (c'est vrai on dit toujours que dans du libre on peut corriger et améliorer les programmes) ^^

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # grin... pas dans debian ?

    Posté par  (site web personnel, Mastodon) . Évalué à 0.

    Dommage, grin ne semble pas être dans debian, y compris sid (ou bien l'aurais-je raté ?)

    WeeChat, the extensible chat client

  • # git grep

    Posté par  . Évalué à 1.

    git grep > ack > grep
    grep pour le grep "generique" vu que ack fait comme git grep et .. heu..ben git grep étant inclus dans git, voila, voila

    • [^] # Re: git grep

      Posté par  . Évalué à 8.

      "git grep" a un inconvénient de taille, il faut utiliser git, donc il ne s'utilise pas dans tout un tas de cas d'utilisations.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # grep -r

    Posté par  . Évalué à 1.

    man rgrep

  • # UUOG

    Posté par  . Évalué à 3.

    Déjà, si après le UUOC, on pouvait lancer un UUOG(rep) pour tous ceux qui tubent des greps avec des sed ou des awk…

    Exemples : grep toto | sed 'bla' → sed '/toto/ bla'
    grep toto | awk '{bla}' → awk '/toto/ {bla}'

    Et si vous trouvez que grep ne va pas assez vite, essayez l’option -F pour les recherches de chaînes simples, ou de préfixer avec LANG=C pour contourner la lente gestion d’UTF-8.

    • [^] # Re: UUOG

      Posté par  . Évalué à 3.

      Déjà si on pouvait expliquer aux gens qui utilisent toujours sed et awk que Perl fait la même chose avec un seul outil... voila voila...

      --> [ ]

  • # sinon, il y a agrep aussi

    Posté par  (site web personnel) . Évalué à 1.

    C'est une version de grep qui gere un certain nombre d'erreurs dans le motif recherche.
    La classe quoi. ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.