Ligne de commande Restez ZEN avec ZSH

Posté par (page perso) . Modéré par patrick_g.
Tags :
17
24
mar.
2009
Ligne de commande
Comme vous le savez tous ZSH est le meilleur shell, mais il lui manquait un atout fort pour conquérir le monde comme il se doit. La dernière brique est maintenant posée, voici la version 0.1 de ZEN (Zsh Extended Network). ZEN est une sorte de CPAN pour ZSH, il se veut une compilation de scripts disponibles pour tous les utilisateurs.

Les fonctionnalités suivantes sont déjà disponibles :
  • Un client permet d'installer, mettre à jour et gérer les dépendances ;
  • Un client nopaste pour rafb.net ;
  • Un client urlalacon ;
  • Des fonctions pour faire des get/post et download de fichiers texte sur le protocole HTTP ;
  • Une fonction d'envoi de mail.
Le tout en pur zsh (pas d'appel à des binaires externes). Si vous voulez participer n'hésitez pas à nous envoyer vos scripts via le gestionnaire de ticket, à venir discuter de zen sur #zsh-fr, etc.

ZEN se veut aussi un bac à sable pour le ZSH upstream, ainsi des fonctions utiles pourront être reprises et intégrées upstream au goût des développeurs ZSH.

La licence est ZSH (BSD-like).
  • # ZEN c'est zen !

    Posté par (page perso) . Évalué à  5 .

    Moi je dis c'est magique zen :

    % zen search zle

    Package | Description
    -----------------------------------------------------------------------------------------------------------------
    zsh/zle/insert-root-prefix | Insert sudo or pfexec in the beginning of the line
    zsh/zle/dirname-current-arg | replace current argument by its parent directory
    zsh/zle/previous-file-nocomp | replace current argument by the previous file as if you were
    zsh/zle/next-file-nocomp | replace current argument by the next file as if you were



    % zen install zsh/zle/insert-root-prefix
    INF: Installing package zsh/zle/insert-root-prefix
    % zle -N zsh/zle/insert-root-prefix
    % autoload -U zsh/zle/insert-root-prefix
    % bindkey '^[v' zsh/zle/insert-root-prefix

    Et hop j'ai mon widget zle qui rajoute pfexec (ou sudo, sur les autres OS) en début de ligne quelque soit la position de mon curseur!
    • [^] # Re: ZEN c'est zen !

      Posté par . Évalué à  1 .


      WARN: /home/alexis/.zen already exists, do you want to delete it and reinstall?
      WARN: If you choose yes, /home/alexis/.zen wil be DELETE!
      [y/n]: y
      INF: ZEN will use /home/alexis/.zen as repository
      INF: Downloading data/catalog
      url_encode:2: invalid base (must be 2 to 36 inclusive): -16


      Hmmm .... :)
      • [^] # Re: ZEN c'est zen !

        Posté par (page perso) . Évalué à  0 .

        il n'y a pas de url_encode dans zen, tu dois surement avoir des trucs perso qui conflict.
        • [^] # Re: ZEN c'est zen !

          Posté par . Évalué à  1 .

          C'est au bootstrap, désolé j'avais pas précisé.
          • [^] # Re: ZEN c'est zen !

            Posté par (page perso) . Évalué à  2 .

            si tu pouvais nous ouvrir un bug en précisant la version zsh et tout ce qui va avec ça nous aidera bien à corriger ça, merci.
            • [^] # Re: ZEN c'est zen !

              Posté par . Évalué à  1 .

              Désolé, ça venait de zsh-beta d'ubuntu qui faisait tout planter. En installant la version normale, c'est impec, merci!
          • [^] # Re: ZEN c'est zen !

            Posté par (page perso) . Évalué à  3 .

            Au fait félicitation à toi tu as trouvé notre premier bug non trouvé par quelqu'un du projet :) et il y en a certainement d'autres (c'est un 0.1) avis aux amateurs
      • [^] # Re: ZEN c'est zen !

        Posté par (page perso) . Évalué à  2 .

        Tiens, étrange.. Tu as utilisé le repo normal ? Tu es derrière un proxy ?


        Au passage il y a un bug tracker sur dev.keltia.net/projects/zen (bon par contre faut s'inscrire et tout.. on a prévu un script zen pour reporter un problème !)

        Tu peux passer sur irc , #zsh-fr sur freenode ?

        Merci d'avance
    • [^] # Re: ZEN c'est zen !

      Posté par . Évalué à  -3 .

      Et ben avec un autre shell :
      # apt-get install sudo

      Et hop, j'ai mon package qui rajoute sudo. En plus ça se limite pas à zsh. Donc je ne vois pas ce qu'apporte ZEN ici...

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

      • [^] # Re: ZEN c'est zen !

        Posté par (page perso) . Évalué à  4 .

        ça serait pas mal de lire un peu le post précédent, le monsieur ne dit pas que insert-root-prefix est un sudo, mais qu'il rajoute sudo (sur les os le supportant) pfexec (sur -open-solaris) en début de ligne. Bref c'est un widget zle qui une fois bindé à ctrl-v (comme dans son exemple) te permet de palier à l'oublie de sudo/pfexec en début de commande, juste un truc super pratique (pour ce qui ne savent pas zle fait le même boulot que readline et même plus :))
        • [^] # Re: ZEN c'est zen !

          Posté par . Évalué à  2 .

          Ah c'est ça, j'avais compris que ça lui installait un script capable de faire du pfexec/sudo-like... Forcément, je ne pigeais pas l'intérêt...

          Au temps pour moi !

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

    • [^] # Re: ZEN c'est zen !

      Posté par Anonyme . Évalué à  1 .

      Vu comme ça, ça semble simple.
      Je suis en train de tester pour l'instant. Je me base aussi sur cette page : http://zshwiki.org/home/zen?s=zen

      J'ai installé zsh/scripts/mail/send

      Comment je fais pour l'utiliser ? J'ai compris où se trouvent les fichiers des fonctions, mais je n'arrive pas à les utiliser. J'ai pourtant bien réglé mon fpath() dans mon .zshrc
      • [^] # Re: ZEN c'est zen !

        Posté par (page perso) . Évalué à  2 .

        Salut Nicolas,

        alors, on utilise la fonctionnalité d'autoload de ZSH. Donc, si tu as bien fais le zen install zsh/scripts/mail/send, et que tu as bien $HOME/.zen/zsh/scripts dans ton fpath, il te suffit de faire :

        % autoload -U mail/send
        % mail/send -f dieu@foo.bar -t jesus@boo.far -s mysmtp.foo.bar -d fichier


        Où fichier est un fichier texte brut contenant les données à passer à la commande DATA SMTP (i.e. From: <dieu@foo.bar> etc)

        Par contre je viens de voir que j'ai petit bug sur l'affiche du usage, mais il devrait fonctionner quand même. N'hésite pas à le dire si ce n'est pas le cas, genre sur le redmine :)

        Bon courage
  • # Vendredi

    Posté par . Évalué à  1 .

    Comme vous le savez tous ZSH est le meilleur shell

    On est pourtant pas encore vendredi ...
    • [^] # Re: Vendredi

      Posté par . Évalué à  10 .

      C'est valable tous les jours.

      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: Vendredi

      Posté par (page perso) . Évalué à  0 .

      Faut attendre le vendredi pour mentir ? (Nan parce que bon tout le monde sait que le meilleur shell au monde c'est powershell)
      • [^] # Re: Vendredi

        Posté par (page perso) . Évalué à  1 .

        C'est peut être vrai mais powershell sur un unix ca va être difficile je pense :)

        Mais j'avoue, le concept est quand même super intéressant..
        • [^] # Re: Vendredi

          Posté par . Évalué à  1 .

          Ben avec Mono, ça doit pouvoir se faire, non ?

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

      • [^] # Re: Vendredi

        Posté par (page perso) . Évalué à  1 .

        Mais non, le meilleur shell, c'est ksh, le Korn shell ! C'est ce que j'ai cru pendant 10 ans avant d'utiliser bash. Maintenant, on veut me faire avaler que c'est zsh... Alors qui croire ?

        Plus sérieusement, J'ai un peu utilisé zsh il y a quelques années. J'ai apprécié quelques unes de des fonctionnalités. Cependant, sortir du standard n'en vaut la peine que si les avantages que l'on en retire sont nettement supérieurs aux inconvénients. Et là, je dois dire que je n'ai pas été vraiment convaincu car les avantages de la standardisation l'ont emporté sur la nouveauté.
        • [^] # Re: Vendredi

          Posté par (page perso) . Évalué à  5 .

          Euh le standard c'est pas bash, faut pas croire, le seul standard c'est le sh posix, sinon sur les unix en général, le standard de fait c'est ksh (attention toutes les implémentations ne se valent pas). Bash est standard uniquement sur linux, et linux n'est pas encore l'unix (plus like que unix) majoritaire (sauf pour l'hébergement web et quelques autres domaines spécifiques) même si il tend fortement à le devenir. Donc l'argument du je prends bash parce que c'est standard est complètement faux.
  • # Gestionnaires de paquetage

    Posté par (page perso) . Évalué à  3 .

    J'ai une vraie question en forme troll : pourquoi un énième système de paquetage ?

    Python a son distuil, TeX son CTAN, Perl son CPAN, sans compter les DEB et autres RPM, etc.

    Je n'arrive pas à trouver un argument rationnel suffisamment fort pour justifier l'absence de coordination au niveau des formats et des protocoles à ce niveau. Qu'est-ce qui empêcherait d'avoir un système unifié au niveau format, quitte à avoir des implémentations dans tel ou tel langage, quand on veut minimiser les dépendances ?

    On m'a soufflé à l'oreille que CPAN6 cherchait à faire ça ? Le putch raté de LSB pour RPM aurait-il stoppé net des velléités de type freedesktop dans ce domaine ? quidquid latine dictum sit, altum sonatur ?

    En même temps, comme je n'y connais rien, je dois rater l'argument massue qui justifie tout ce temps perdu, cette interopérabilitée ratée et cette complexification inutile... aidez-moi à comprendre.
    • [^] # Re: Gestionnaires de paquetage

      Posté par (page perso) . Évalué à  2 .

      Bonjour,

      alors, déjà, ce n'est PAS un système de package. On télécharge juste des fichiers texte, en http, ces fichiers sont directement les scripts.

      Le pourquoi, c'est simple, pour être totalement indépendant de l'OS. Pour ma part je code sur OpenSolaris, Mac, bapt sous FreeBSD (et Linux) alors va trouver un système de packaging commun..

      On veut pas remplacer les deb et RPM hein, c'est juste pour gérer des scripts, rien de plus, et en pure zsh, pour pas être dépendant de softs qui se trouvent pas sur certains systèmes exotiques...
    • [^] # Re: Gestionnaires de paquetage

      Posté par (page perso) . Évalué à  3 .

      En même temps, comme je n'y connais rien, je dois rater l'argument massue qui justifie tout ce temps perdu, cette interopérabilitée ratée et cette complexification inutile... aidez-moi à comprendre.

      Alors, le temps perdu : se faire plaisir ! Coder un système de package avec notion de dépendances en à peine 50 lignes de shell, c'est <3
    • [^] # Re: Gestionnaires de paquetage

      Posté par (page perso) . Évalué à  3 .

      bon alors
      1/ zen n'est pas gestionnaire de package
      2/ on fait ça pour le fun, et pour montrer la puissance de zsh en tant que language de scripts
      3/ on fait ça pour éviter aux gens de réinventer la roues, et notre echo système c'est uniquement zsh et non pas tout un os.

      Ensuite pour la perte de temps ça pourrait bien être le cas si j'avais voulu passer du temps sur deb rpm ou autres, mais non je ne l'ai pas fait donc je ne fais perdre de temps à personne, par contre le mec qui veut se faire des scripts en 2s dans sur un coin de table sera content de trouver un point centrale ou disposer de fonctions déjà existante et fonctionnelles.

      Maintenant si une distrib veut packager le contenu de zen tant mieux même si je ne vois pas trop l'intérêt quel pourrait y trouver.
      • [^] # Re: Gestionnaires de paquetage

        Posté par (page perso) . Évalué à  3 .

        OK, je ne remet pas en cause le fait que a soit fun et tout, c'est un argument tout à fait acceptable. Par contre, j'ai quelques remarque sur les autres arguments.

        Pour commencer, pour moi un gestionnaire de paquets c'est un (ou plusieurs) outils automatisant le processus d'installation, désinstallation, mise-à-jour de logiciels installés sur un système informatique. Il me semble, en tant que béotien incompétent, que cette définition de Wikipédia colle bien à Zen, quand bien même ce serait un gestionnaire très simple et léger par rapport à ce que peuvent faire des trucs comme APT/DEB et compagnie.

        Ensuite, en tant qu'utilisateur lambda, ce que je perçoit (mais c'est sans nul doute un biais, d'où mes questions), c'est que je vais encore devoir me rappeler une autre commande d'installation, qui ne sera pas incluse dans mon interface graphique favorite, que je devrais réussir à faire maintenir par mon adminsys dans un autre dépôt séparé (et qu'il va raler), etc.

        J'imagine (mais je peux me tromper) que si l'on avait un FORMAT de données et un protocole unifié, ça n'enlèverait rien à la portabilité (on peut recoder le système dans le langage de son choix), mais ça aiderait beaucoup à la facilité d'emploi (j'installe avec mon gestionnaire favoris, sans avoir à en apprendre un nouveau).

        Bien sûr, on va me rétorquer que c'est pas compliqué d'apprendre une commande, que ça impose des contraintes aux devs... certes, mais ça ne me parait pas être des arguments très pertinents (on peut en discuter, mais ce serait tellement pénible que ça ne me tente pas trop).

        Bon, désolé que la question soit tombé sur vous, vu que Zen est vraiment le truc tellement simple que ça justifie presque tout, mais il fallait quand même que je pose la question, et il n'y a pas de news sur Python setuptools en ce moment.
      • [^] # Re: Gestionnaires de paquetage

        Posté par (page perso) . Évalué à  5 .

        Maintenant si une distrib veut packager le contenu de zen tant mieux même si je ne vois pas trop l'intérêt quel pourrait y trouver.

        La question de savoir s'il est intéressant de packager des trucs simples, tels que les extensions xpi de mozilla ou les packages pear-* se pose réguliérement.

        Excepté l'application éventuelle de patches, les principaux avantages sont les suivants :

        - référencement : grâce à ses outils habituels (`make search' ou assimilé), l'utilisateur pourra découvrir des applis dont il ne soupçonnait pas l'existence ;

        - utilisation comme dépendance (c'est le cas des pear-*, qu'on installe rarement pour eux même, mais parce qu'ils sont utilisés par d'autres applis) ;

        - installation globale sur un système multi-utilisateurs ;

        - vérification de l'intégrité depuis la source, suivi des mises à jours et des problèmes de sécurité : on délègue ça au mainteneur, et c'est cohérent avec toutes les autres applis installées par ailleurs ;

        - installation cohérente (respect de hier(7)), contrôle de ce qui est installé et désinstallation propre.

        Après, c'est sûr qu'on ne peut pas packager tous les `hello world', et il faut qu'une appli trouve une certaine popularité pour intéresser un mainteneur ! On ne peut que souhaiter à Zen d'atteindre cette reconnaissance...
    • [^] # Re: Gestionnaires de paquetage

      Posté par . Évalué à  1 .

      Dans certain cas c'est pratique.
      Quand je vois qu'hier j'ai pris 20 min a Compiler/Tester SpamAssassin en provenance du CPAN sur un Intel Q6600, pour me dire que certains tests n'étaient pas passés, donc pas d'installation. Et qu'après, en 1 min, je l'ai installé via apt-get...

      Mmmh... Je suis bien content d'avoir le Deb. Même si ce n'est pas toujours les dernières versions.
  • # Le tout en pur zsh

    Posté par . Évalué à  1 .

    Cette news doit bien avoir un sens... Derrière tout se jargon incompréhensible même par le visiteur moyen de LinuxFr (donc pas vraiment une pomme), il doit y avoir des informations utiles... Mais je me demande bien quoi.

    En plus court et en onomatopée : "Gné ?"
    • [^] # Re: Le tout en pur zsh

      Posté par (page perso) . Évalué à  5 .

      bah zsh c'est un shell, qui offre des fonctionnalités de programation très avancées donc on a fait un répertoire de centralisation des fonctions zsh, et contrairement à d'autres shell, on a pas besoin dans la plupart des cas de faire appel à des programmes externes : grep, cat, etc.
      • [^] # Re: Le tout en pur zsh

        Posté par (page perso) . Évalué à  6 .

        Donc zsh réinvente la roue que sont grep, cat, etc :D
        • [^] # Re: Le tout en pur zsh

          Posté par (page perso) . Évalué à  3 .

          Oué mais au moins t'es sûr d'avoir le même comportement partout, quelque soit la syntaxe utilisée. Et me dis pas que ça t'es jamais arrivé d'avoir un script écrit sur du userland GNU et que tu dois exécuter sur autre pas GNU, et que l'auteur à utilisé plein de GNUeries ! Ce n'est en aucun un reproche, juste un constat :)
          • [^] # Re: Le tout en pur zsh

            Posté par . Évalué à  2 .

            >et que l'auteur à utilisé plein de GNUeries !
            Tu viens de comprendre à quoi servent les normes et notamment posix !
            • [^] # Re: Le tout en pur zsh

              Posté par (page perso) . Évalué à  5 .

              JE sais très bien à quoi cela sert. Mais pas tous les gens qui écrivent des scripts, notamment ceux qui commencent par #/bin/sh et qui sont plein de basheries.

              Mais merci de ton illumination extraordinaire !
        • [^] # Re: Le tout en pur zsh

          Posté par . Évalué à  6 .

          En fait, c’est grep, cat, etc. (heu, p’têt pas cat en fait) ont été mal faits : ils auraient dû mettre leurs fonctionnalités dans une bibliothèque que zsh (ou autre) aurait pu réutiliser plutôt que d’obliger soit à lancer un processus supplémentaire et gérer des tubes, soit à recoder le bousin.

          Et puis, lancer des tas de processus, ça permet quand même d’utiliser tous ces cœurs qu’on nous met dans nos processeurs et qui nous servent à rien…
  • # [HS] question sur Zsh

    Posté par . Évalué à  5 .

    Peut-on colorer la ligne de commande sur zsh ? par exemple :
    $ ca # ça reste rouge ; la commande est inconnue
    $ cat # ça devient écrit en vert ; le programme existe bien

    $ hg commit -m "coucou" # coucou est en jaune

    J’ai vu ce truc sous le shell « fish », et j’ai trouvé ça super ! Par contre je n’ai rien vu de semblable sous bash… Alors qu’en est-il du « meilleur shell » zsh ? :)
    • [^] # Re: [HS] question sur Zsh

      Posté par (page perso) . Évalué à  1 .

      Alors, il me semble avoir vu passé une discussion à ce sujet, mais je préfère te répondre que malheureusement non, y a pas ça dans zsh. Je vais essayer de creuser un peu...
      • [^] # Re: [HS] question sur Zsh

        Posté par (page perso) . Évalué à  2 .

        Juste pour compléter, je pense que techniquement c'est possible sans modifier zsh en soit, mais que ce n'est pas trivial, à ma connaissance il n'y a pas de solution toute faite. mais c'est à creuser.
    • [^] # Re: [HS] question sur Zsh

      Posté par (page perso) . Évalué à  2 .

      Je ne connais pas bien Zsh, mais je peux juste te dire qu'il y a tellement de chose bien dans fish que cet exemple ne représente qu'une infime partie.

      Sérieusement, j'ai toujours pensé que bash était suffisament bon pour ne pas avoir à changer. J'avais testé rapidemment Zsh puisque tout le monde en parlait, mais ça ne m'a pas tenté. Par contre, 5 min d'utilisation de fish et c'est maintenant mon shell par défaut.

      Sa complétion est impressionnante, il a une coloration syntaxique pour tout, ses commandes et structures sont cohérent, la recherche dans l'historique est simplifié, l'aide bien faite etc...

      Quelqu'un s'y connaissant pourrait préciser quels sont les vrais atouts de Zsh par rapport à Fish? J'avoue être curieux.
      • [^] # Re: [HS] question sur Zsh

        Posté par (page perso) . Évalué à  5 .

        zsh-iste convaincu, je viens d'essayer fish, et c'est vrai qu'il n'est pas désagréable comme shell à écrire des commandes simples. Cependant, en trois minutes, je lui trouve quelques défauts, :

        Il est lent ('echo **/*.tex' dans mon home prend 8 secondes avec fish alors que c'est instantané dans zsh). De même, for est d'une lenteur exaspérante !

        Sa complétion des commandes avec wildcards ne sert à rien (il trouve les commandes qui matchent mais il ne fait pas le remplacement et me dit par exemple "fish: Illegal command name “m*tt”")

        Il a des complétions pour quelques commandes mais pas autant que zsh ou bash et celles que j'ai essayées sont moins intelligente : celle de mplayer par exemple comprend moins d'options que celle de zsh, celle d'apt-get est moins intelligente (il me propose tous les paquets quand je veux supprimer, zsh ne me propose que ceux qui sont installés). Si tu trouves la complétion de fish impressionnante, réessaye celle de zsh ou celle de bash, elles sont encore meilleures.

        Il se scripte de façon non standard (c'est peut-être un avantage en fait, la syntaxe posix des scripts shell n'est pas d'une logique formidable, mais c'est déstabilisant).

        Il n'a pas de page de man (enfin c'est juste une caricature, elle a moins de 20 lignes) et je n'apprécie pas qu'il ouvre un navigateur pour m'afficher la doc pour for.

        Il lui manque des built-ins indispensables (time, which, where).

        Il ne sait pas corriger les noms de commandes ou d'arguments mal orthographiés !
        • [^] # Re: [HS] question sur Zsh

          Posté par . Évalué à  2 .

          « Il a des complétions pour quelques commandes mais pas autant que zsh ou bash »

          C’est un shell peu connu, il y a donc sans doute moins de contributions externes…
          Quand à la complétion plus intelligente sous bash ou zsh, je pense qu’on peut arriver à la même chose sous fish… question de temps sans doute.
        • [^] # Re: [HS] question sur Zsh

          Posté par (page perso) . Évalué à  2 .

          Bon moi j'adore que fish me mette des couleurs partout, j'adore qu'il me donne une descriptions rapide de toutes les options par simple tab. Bash/Zsh ont peut-être une complétion plus intelligente, elle n'en reste pas moins moins utilisable (pour moi) car pas de description.

          La lenteur je m'en fiche, je l'ai aussi remarqué, mais je m'en sers comme shell intéractif, rien d'autre. Des que je veux faire un truc plus complexe je met ça dans un script sh/bash. Je ne connais pas et n'ai pas besoin d'apprendre sa syntaxe de for/while.

          Et moi j'aime qu'il m'ouvre un navigateur ^^

          Bref, on ne l'utilise sans doute pas pour les même choses. Pour moi, il me sers a taper des commandes simples, me faire une autocomplétion, et rechercher dans l'historique. Et pour ça je le trouve bien plus user-friendly que bash.
          • [^] # Re: [HS] question sur Zsh

            Posté par (page perso) . Évalué à  5 .

            > j'adore qu'il me donne une descriptions rapide de toutes les options par simple tab. Bash/Zsh ont peut-être une complétion plus intelligente, elle n'en reste pas moins moins utilisable (pour moi) car pas de description.

            Si si, zsh donne des descriptions des options. Quand je fais rubber -<tab>, j'ai droit à des lignes comme
            --clean -- remove produced files instead of compiling
            --command -c -- run the directive CMD before parsing

            L'option longue, l'option courte équivalente si elle existe, ce qu'elle fait.
  • # shell a mon pb : les habitudes

    Posté par (page perso) . Évalué à  1 .

    Pour essayer zsh depuis qq temps sur mon desktop (en faite depuis que bapt à fait un how-to sur le forum gentoo), je suis d'accord sur le faite que zsh est une pure tuerie.

    Sauf que, au taff je suis obligé de me farcire un bon vieux ksh des familles (hp-ux vieux de 4 ans), et sur les autres projets annexes, je doits utiliser bash.

    Au final, je doit passer à côter des merveilles de zsh pour coder, et plus le temps passe plus le manque de fonctionnalités des 2 autres me gènes. A tel point que parfois je retourne sous bash sur mon desktop. Oui je sais c'est un peu bizard.

    Ma gène est donc : foncer dans les méandre du bonheur d'utilisation de zsh et me forcer à maitriser zsh et POSIX afin d'être interopérable, ou tout simplement me concentrer sur POSIX ?

    Bon je crois que faire des geekeries y a que ça de vrai ;)
    • [^] # Re: shell a mon pb : les habitudes

      Posté par (page perso) . Évalué à  2 .

      Je viens de voir le changelog de bash 4.0 et j'y ai trouvé trois nouveautés importantes :
      w. There is a new shell option: `globstar'. When enabled, the globbing code
      treats `**' specially -- it matches all directories (and files within
      them, when appropriate) recursively.


      Enfin, le truc indispensable qui me fait maudire tous les shells autres que zsh !

      ii. The shell provides associative array variables, with the appropriate
      support to create, delete, assign values to, and expand them.


      Je ne savais même pas qu'il n'y en avait pas dans bash ! C'est tellement utile dès qu'on fait des scripts un tout petit peu évolué !

      r. There is now limited support for completing command name words containing
      globbing characters.


      Encore heureux ! Ce n'est pas indispensable mais quand même super pratique.

      Donc ma question, manque-t-il encore des choses à bash pour qu'il soit prêt pour le desktop ?
  • # Historique zsh

    Posté par Anonyme . Évalué à  1 .

    J'en profite pour tester un peu zsh. Je suis très habitué à tcsh et à son super historique (si je tape l et que j'appuie sur la flèche du haut, il va me sortir toutes les commandes commençant par l dans mon historique). Super pratique. Cela ne fonctionne pas dans zsh, qui se comporte comme bash et ksh : on liste toutes les commandes dans l'ordre chronologique, même si tu as commencé à taper une commande.

    Est-ce possible ? Ou il n'y a que tcsh pour cette fonction ?

    Merci.
    • [^] # Re: Historique zsh

      Posté par (page perso) . Évalué à  6 .

      Bien sûr que c'est possible, il suffit d'avoir la bonne configuration.

      Voici comment j'ai remappé dans Zsh les touches PgUP et PgDN pour avoir la fonctionnalité dont tu parles :

      bindkey '^[[5~' history-beginning-search-backward # PgUp
      bindkey '^[[6~' history-beginning-search-forward # PgDn
      • [^] # Re: Historique zsh

        Posté par Anonyme . Évalué à  1 .

        Excellentissime. Je continue mon apprentissage de zsh !
    • [^] # Re: Historique zsh

      Posté par . Évalué à  1 .

      Sous bash :

      poiuy@debian:~$ grep -A 2 alternate /etc/inputrc
      # alternate mappings for "page up" and "page down" to search the history
      # "\e[5~": history-search-backward
      # "\e[6~": history-search-forward

Suivre le flux des commentaires

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