Journal Autojump - avec l'auto-complétion maintenant!

Posté par  (site web personnel) .
Étiquettes :
6
20
fév.
2009
Bonjour à tous,

vous vous souvenez peut-être de la dépêche assez controversée annonçant la naissance d'autojump, un outil pour parcourir plus rapidement le système de fichiers en ligne de commande: http://linuxfr.org/2009/02/13/25023.html

Autojump a pas mal progressé depuis la dépêche, et supporte maintenant l'auto-complétion. Cela permet de vérifier à quel endroit on va sauter avant d'y aller effectivement, et le cas échéant, de choisir un autre endroit. Cette modification (qui avait été suggérée par des lecteurs de linuxfr!) rend l'outil encore plus pratique à utiliser.

D'autres part de nombreux bogues on été corrigés, en particulier pour l'installeur semi-automatique qui devrait marcher sous la plupart des distributions.

La dernière version se trouve ici: http://sd-12155.dedibox.fr/~joel/public/autojump.tar.gz

Le projet est toujours sous github:
http://wiki.github.com/joelthelion/autojump

PS: pour les utilisateurs d'arch linux, le paquet autojump a été mis à jour sur AUR.
  • # Prem's

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

    Je n'avais pas testé la version précédente d'Autojump, mais je dois dire que le concept m'avait bien plus.

    Je viens de le déployer sur une machine virtuelle (je suis sous Windows au taf) et ça fonctionne bien.

    Merci pour ce petit utilitaire bien pratique.

    Juste une petite question. Pourquoi jstat demande-t-il la présence de sun-java5-jdk ou sun-java6-jdk ? Un JRE ne serait-il pas suffissant ?
    • [^] # Re: Prem's

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


      Juste une petite question. Pourquoi jstat demande-t-il la présence de sun-java5-jdk ou sun-java6-jdk ? Un JRE ne serait-il pas suffissant ?


      Ah, merci de la remarque! En fait la commande s'appelle jumpstat maintenant, précisément pour éviter la collision avec cet utilitaire sans rapport (qui appartient au jre je crois). J'ai juste oublié de mettre la doc à jour.
  • # Excellent

    Posté par  . Évalué à 3.

    Ca a l'air tres bien tout ca :)

    Il se base sur quoi pour trouver le dossier ? L'historique de 'cd' ou les dossiers existants sur le disque ?

    $ j --help
    Unknown command line argument: option --help not recognized
    • [^] # Re: Excellent

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

      Comme expliqué dans la page de man ( :) ), il crée une petite "base de données" qui stocke le nombre de commandes que tu as executé à partir de chaque répertoire.

      Ensuite, quand tu tappes j "motif", il t'emmène au répertoire le plus populaire qui correspond au motif (ou t'affiche la liste dans l'ordre de popularité si tu fais tab pour avoir les complétions).
      • [^] # Re: Excellent

        Posté par  . Évalué à 3.

        Merci !

        Donc si je comprends bien, il y a une phase d'apprentissage pour l'outil.

        (...)

        Ah oui, ca aussi, c'est écrit dans la page de man.... :)
        • [^] # Re: Excellent

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


          Donc si je comprends bien, il y a une phase d'apprentissage pour l'outil.


          Tout à fait, même si elle est assez rapide (un jour tout au plus pour que ça soit utilisable). La commande "jumpstat" permet de voir l'état actuel de la base de données.
          • [^] # Re: Excellent

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

            Ok, je comprends mieux l'histoire du jstat qui correspondait à Java Virtual Machine Statistics Monitoring Tool

            Il faudra mettre à jour le fichier README par contre (il fait toujours référence à jstat)
  • # Flemme de lire le code source

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

    Et en plus je ne connais pas bien python, mais j'ai une question : comment sont « notées » (score) les entrées dans la base de données ? Tu incrémentes le score de « /usr/share/doc » à chaque fois qu'on fait « cd /usr/share/doc » ? Ou tu comptes le temps passé dans chaque répertoire (= à chaque seconde tu fais ++/usr/share/doc) ? La deuxième solution me semble bien plus lourde, et à la réflexion pas très pertinente.

    Je suppose donc que c'est la première possibilité. Dans ce cas là, est-ce que tu prends aussi en compte, pour augmenter le score, d'autres commandes qui mènent à un répertoire, par exemple :
    - cd -
    - popd
    - et autojump
    • [^] # Re: Flemme de lire le code source

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

      Et en plus je ne connais pas bien python, mais j'ai une question : comment sont « notées » (score) les entrées dans la base de données ? Tu incrémentes le score de « /usr/share/doc » à chaque fois qu'on fait « cd /usr/share/doc » ? Ou tu comptes le temps passé dans chaque répertoire (= à chaque seconde tu fais ++/usr/share/doc) ? La deuxième solution me semble bien plus lourde, et à la réflexion pas très pertinente.

      Ce n'est ni l'une ni l'autre :) En fait je compte le nombre de commandes effectuées à partir de chaque répertoire. Par exemple, si tu es dans /usr/share/doc et que tu fais "ls", le score de ce répertoire sera incrémenté de 1. De cette manière je n'ai pas les problèmes que tu décris.
      • [^] # Re: Flemme de lire le code source

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


        for i in `ls *`: do echo $i; done

        ça compte pour 1 ?


        Y a-t-il des profils/sessions ? Aujourdhui, je travaille sur tel projet, donc je veux tel état immédiatement. Demain, je serai de retour sur un autre projet, donc je veux pas devoir tout lui réapprendre et être directement avec des scores adaptés.
      • [^] # Re: Flemme de lire le code source

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

        Ce n'est ni l'une ni l'autre :) En fait je compte le nombre de commandes effectuées à partir de chaque répertoire. Par exemple, si tu es dans /usr/share/doc et que tu fais "ls", le score de ce répertoire sera incrémenté de 1. De cette manière je n'ai pas les problèmes que tu décris.
        Mouais, mais est-ce pertinent dans tous les cas ? Par exemple, ne faudrait-il pas ignorer les commandes qu'on peut effectuer depuis n'importe où, du genre cp /etc/X11/xorg.conf /tmp ? Que je tape cette commande depuis /usr/share/doc ou depuis /var/log ne change strictement rien.
        • [^] # Re: Flemme de lire le code source

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

          Bien entendu, ce n'est pas parfait, mais il est important que ça reste simple et rapide, puisque c'est effectué à chaque affichage de prompt. Personnellement je trouve les stats assez exactes et autojump fait très peu d'erreurs.

          Evidemment si tu as une meilleure idée je serais ravi de l'entendre :)
          • [^] # Re: Flemme de lire le code source

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

            Eh bien mon idée (cf. premier commentaire) de compter toutes les commandes qui mènent à un répertoire, et seulement celles-ci, me semblent pertinente. Puisque ce qu'on cherche à éviter c'est de taper cd /mon/chemin, il me semble logique de compter le nombre de fois qu'on cd dans tel ou tel endroit.

            Mettons par exemple je tape une seule fois par jour (disons le matin en arrivant) cd /mon/répertoire/de/projet/tmp et 50 fois cd ~/mnt/tmp ; mettons que toutes les 5 minutes je tape make ou xemacs projet.c dans mon shell /mon/répertoire/de/projet/tmp, mais que dans ~/mnt/tmp je ne tape à chaque fois qu'une seule commande avant de fermer mon shell. Dans ce cas, le score de « /mon/répertoire/de/projet/tmp » va monter en flèche, alors que celui de ~/mnt/tmp va rester assez bas. Pourtant, quand je tape j tm, ce qui me facilite le plus la vie c'est qu'il aille dans ~/mnt/tmp (puisque j'y vais beaucoup plus souvent).

            (J'espère que c'est assez clair.)

Suivre le flux des commentaires

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