À la (re)découverte de Zsh

Posté par (page perso) . Modéré par Pascal Terjan.
Tags :
0
10
sept.
2006
Linux
En ces temps nouveaux où les effets spéciaux sont de mise, où on veut un bureau en 3D avec des paillettes et des widgets qui brillent, votre meilleur ami est et restera toujours votre shell (ceux qui pensent le contraire sont peut-être encore un peu jeunes). Aujourd'hui votre shell est sans aucun doute le shell par défaut de votre système d'exploitation, j'ai nommé GNU Bash (ou Csh ?[1]). Seulement, en avez-vous testé d'autres ?

Parmi les autres shells, laissez-moi vous présenter Zsh, la Rolls des shells, il est rapide, léger, extensible et il a des possibilités que vous ne soupçonnez pas encore : une auto-complétion enviée par les autres shells, un langage de script avancé, des modificateurs, le globbing (ou comment oublier find), création d'alias évolué, etc.

Le langage de script de zsh est très évolué et permet de faire du matching, du remplacement, des découpes de chaînes, des manipulations de tableaux, donc plus besoin de faire appel à des outils externes comme grep, sed, cut, awk, etc. À l'heure où beaucoup de distributions Linux essaient de minimiser la durée du processus de démarrage, certains se demandent[2] pourquoi zsh n'est pas utilisé dans les scripts d'init à la place de bash ou dash pour éviter tous ces appels systèmes et gagner en temps d'exécution.

Si vous êtes convaincus, il existe des ressources pour apprendre et participer à la promotion de zsh :
- la documentation[3]
- un wiki[4] francophone dédié aux applications CLI
- une liste de diffusion[5] francophone dédiée aux shells en général
- le ZshWiki[6] Petite présentation de quelques possibilités de zsh :
===============================

o Les Variables :
----------------

+ déclaration d'une variable contenant une chaîne
de caractère et affichage de sa taille :

,------ [code] ---
| % mavar="welcome to linuxfr"
| % echo "strlen(\$mavar)=${#mavar}"
| 18
`-------------------------------------

o Les Tableaux :
--------------

+ déclaration d'un tableau, affichage du second élément et
affichage de sa taille :

,------ [code] ---
| % array=(8 2 4)
| % echo $array[2]
| 2
| % echo ${#array}
| 3
`-------------------------------------

+ déclaration d'une variable contenant une chaîne
puis découpage sur le caractère '/' et stockage dans un tableau
et enfin affichage du second élément du tableau :

,------ [code] ---
| % mypath="/var/log/messages"
| % myfiles=(${(s:/:)mypath})
| % echo $myfiles[2]
| log
`-------------------------------------


o Les Modificateurs :
----------------

+ dirname :

,------ [code] ---
| % file="/etc/apache2/sites-available/default"; echo ${file:h}
| /etc/apache2/sites-available
`-------------------------------------

+ basename :

,------ [code] ---
| % file="/etc/apache2/sites-available/default"; echo ${file:t}
| default
`-------------------------------------

+ extension :

,------ [code] ---
| % file="truc.txt"; echo ${file:e}
| txt
`-------------------------------------

+ sans l'extension :

,------ [code] ---
| % file="truc.txt"; echo ${file:r}
| truc
`-------------------------------------

o Le Globbing :
--------------

+ matcher une série d'entiers :

,------ [code] ---
| % ls plop
| plop10 plop11 plop12 plop13 ... plop19 plop20
| % ls plop
| plop10 plop11 plop12 plop13 ... plop100 plop101 plop102
`-------------------------------------

+ ne lister que les liens :

,------ [code] ---
| % ls -dF *(@)
| link1@ link2@
`-------------------------------------

+ ne lister que les [-executables-] {+exécutables+} par le [-propriétaire:-] {+propriétaire :+}

,------ [code] ---
| % ls -dF *(x)
| bin1 bin2
`-------------------------------------

+ ne lister que les [-executables-] {+exécutables+} par le propriétaire et par les
autres [-(other):-] {+(other) :+}

,------ [code] ---
| % ls -dF *(X)
| bin6 bin7
`-------------------------------------

+ ne lister que les fichiers lisibles : *(r) et *(R)
+ ne lister que les fichiers inscriptibles : *(w) et *(W)
+ ne lister que les répertoires : *(/)


+ ne lister que les fichiers [-appartenant-] {+appartenant+} à l'utilisateur 'troll' :

,------ [code] ---
| % ls -l *(u[troll])
| -rw------- 1 troll troll 2,3K 2000-01-01 00:42 secret
`-------------------------------------
  • # oops

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

    une petite erreur de copier/coller s'est glissé dans les textes explicatifs des exemples : ne lister que les [-executables-] {+exécutables+} par le [-propriétaire:-] {+propriétaire :+} devait être : ne lister que les exécutables par le propriétaire : ne lister que les [-executables-] {+exécutables+} par le propriétaire et par les autres [-(other):-] {+(other) :+} devait être : ne lister que les exécutables par le propriétaire et par les autres (other) : ne lister que les fichiers [-appartenant-] {+appartenant+} à l'utilisateur 'troll' : devait être : ne lister que les fichiers appartenant à l'utilisateur 'troll' : merci au modérateur qui corrigera et qui supprimera ce commentaire
  • # Zsh Rulez

    Posté par . Évalué à 5.

    Entièrement d'accord pour la qualité de Zsh...
    Pour ma part, je suis pas un grand scripteur shell, mais il me sert quand même grandement pour toutes ses autocomplétions : sur apt-get, sur les arguments de nombreuses commandes, etc...
    La vie est plus facile avec Zsh !!!
    • [^] # Re: Zsh Rulez

      Posté par . Évalué à 4.

      Au passage, bash permet aussi l'autocomplétion sur apt-get, sur les arguments de nombreuses commandes... il suffit de l'activer.

      Il paraît que celle de zsh est meilleure, donc si quelqu'un ayant expérimenté les deux pouvait préciser...
      • [^] # Re: Zsh Rulez

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

        Zsh a un peu d'avance dans ce domaine, mais sous Ubuntu 6.06, je n'en voie presque plus.
        Avant il y avait encore ce genre d'erreur ;-) sous bash :
        * si tu tapais 'cd ' et puis tab, bash te proposait des fichiers aussi !!! Pas zsh ;-) il ne te proposait que des répertoires.
        * si tu tapais 'gunzip ' bash te proposait aussi des fichiers non en .gz Pas zsh
        * etc.

        Maintenant, du moins avec la configuration sous Ubuntu 6.06, je ne vois plus de différence. Mais je peux te dire que je la voyais encore dans la version précédente, la 5.10...

        Jean-Christophe
        • [^] # Re: Zsh Rulez

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

          Ça c'est dépendant de ta distribution. C'est pas la faute de bash si sa configuration sous Ubuntu 5.10 était pourrie.

          L'autocomplétion "intelligente" existe sur bash depuis très longtemps. Tu peux aussi autocompléter les options de programmes : par exemple, "tar[tab]" m'affiche "A c d r t u x". Le fichier qui configure cela (au moins sur ma distro) est /etc/bash_completion et tu peux rajouter tes propres completions dans /etc/bash_completion.d
      • [^] # Re: Zsh Rulez

        Posté par . Évalué à 2.

        Ce que j'aime bien sur zsh c'est que la complétion "corrige" les fautes de frappes, et qu'en répétant la touche tab, on peut choisir avec quel fichier compléter. C'est possible à activer avec bash ?
        Sinon, le problème que j'avais avec zsh (il y a un an, j'ai pas réessayé depuis), c'est qu'une fois qu'il était lancé, zsh ne faisait pas la complétion pour les applications nouvellement installées. C'est possible à activer ? Ca provoque une perte de performance ?
        • [^] # Re: Zsh Rulez

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

          une fois qu'il était lancé, zsh ne faisait pas la complétion pour les applications nouvellement installées

          'rehash' (man zshbuiltins) est ton ami :)
        • [^] # Re: Zsh Rulez

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

          Ce que j'aime bien sur zsh c'est que la complétion "corrige" les fautes de frappes, et qu'en répétant la touche tab, on peut choisir avec quel fichier compléter. C'est possible à activer avec bash ?
          Pour les fautes de frappe y'a un truc du genre
          export CDPATH='.:~:/usr:/opt:/usr/local:/usr/src:/'
          shopt -s cdspell

          Ensuite si tu est dans / et que tu fait cd linux, il va te mettre dans /usr/src/linux.
          Même chose si tu est dans "/usr/src" et que tu tappe "cd ljnux".

          Sinon les truc comme
          ls plop<10-20>
          peuvent se faire avec ls plop{10..20} (en zsh aussi d'ailleurs)

          Enfin, faudrais demander à un gourou du bash pour plus de précision.
          Par ailleur y a l'inverse des choses dont je ne suis pas sûr qu'elles soient possibles en zsh. Notement l'utilisation de /dev/tcp/ (apparement ils ont genre de netcat à la place); ou les multiples raccourcis emacsiens.

          Ceci dit je doit reconaître que la syntaxe pour les redirections m'a l'air bien plus propre, et que j'envisagerais sérieusement de remplacer bash (j'étais resté sur une idée de zsh comme d'un vieux truc pas maintenu, il se révèle plus intéressant que ça).
          • [^] # Re: Zsh Rulez

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

            Côté redirections, avant de découvrir zsh, j'avais :

            * tcsh: pratique, mais incomplet. Dans 99% des cas, on redirige stdout, ou bien les deux, et là "toto.sh >& /dev/null" est hyper pratique

            * (ba)sh: on peut tout faire (y compris ne rediriger que stderr), mais le 2>&1 > /dev/null est vraiment lourd.

            et en zsh, y'a les deux syntaxes ;-).
  • # Oui mais ...

    Posté par . Évalué à -10.

    ... Ce genre de "news" a plus sa place dans un journal AMHA ...
    • [^] # Re: Oui mais ...

      Posté par . Évalué à -8.

      Eh bé ct pas méchant pas la peine de s énerver, mais là c est un bon article sur un shell pas une news sur un nouveau logiciel/kernel/desktop/... !! :(
    • [^] # Re: Oui mais ...

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

      Au contraire, je trouve l'idée très intéressante.

      Si les liens tout en haut de la page sont appelés « Dépêches » et « Proposer une dépêche », le lien sur lequel je clique est intitulé « Lire l'article ».

      Il serait bien dommage que la page principale soit réduite à l'état d'un téléscripteur, parfois à retardement.

      Cet article a très certainement fait découvrir Zsh à certains lecteurs. D'autres, comme moi, qui le connaissaient ou l'utilisaient déjà ont pu y trouver des astuces. Certains commentaires ont probablement même servi à améliorer la configuration de Bash (!) chez quelques personnes.

      Je serais heureux que de temps à autres, on retrouve un article de ce type, sur un logiciel qui mérite d'être mieux connu.

      Je pense (et à voir ta note, je ne suis pas le seul ici, même si personne n'a daigné te répondre avant moi) que cette catégorie d'article « découverte » mérite largement une place en première page.
      • [^] # Re: Oui mais ...

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

        Je pertinente !
        Des news de ce genre, j'en voudrais plus souvent, cela m'a fait découvrir Zsh que j'utilise maintenant ... très agréable. Surtout niveau completion qui se fait en dessous de la ligne de commande et disparaît après (ca ne fait pas scroller le terminal et on garde de vue les commandes d'avant.

        Et aussi niveau prompt, j'aprécie RPS1, le prompt à droite.
        Dans PS1, j'ai les infos de d'habitude, username, hostname et dossier courant que je limite a deux niveaux (limite la tailel du prompt dans les niveaux profonds.
        Dans RPS1, le dirname complet dans une couleur pau contrastée. Et disparaît automatiquement lorsque le curseur arrive dessus.

        En plus, la couleur change selon le succès de la commande d'avant, super pratique et merci a la personne qui a donné l'astuce sur cette page.

        prompt(){
        autoload colors
        colors
        reset="$terminfo[sgr0]"
        bold="$terminfo[bold]"
        color_isok="%(?.%{$bold$fg[green]%}.%{$bold$fg[red]%})"
        # %(!.#.$) to have '$' or '#' sign like bash / %# to have either '%' or '#'
        export PS1="$color_isok%n@%M%{$reset%}:%{$bold$fg[blue]%}%2~%{$reset%}%(!.#.$) "
        export RPS1="%{$fg[yellow]%}%~%{$terminfo[sgr0]%}"
        }
        • [^] # Re: Oui mais ...

          Posté par . Évalué à 1.

          Effectivement, la colorisation est très sympathique et le répertoire à droite de la ligne très intéressante...

          Par contre, la ligne définissant PS1 ne marchait pas telle quelle. Je l'ai modifiée ainsi:

          export PS1="$color_isok%n@%M%{$reset%}:%{$bold$fg[blue]%}%2~%{$reset%}> "

          Sinon ca me faisait une erreur...
  • # ZSH: autres fonctionnalites

    Posté par . Évalué à 4.

    Bonjour.

    Je ne connaissais pas toutes les syntaxes utilisees ici. Merci.


    J'utilise zsh et il vraiment tres complet. En plus de ce qui a ete dit, il gere la completion sur le man, sur apt-get et sur plusieurs programmes (par exemple pour connaitre les option d'un prog, il suffit d'ecrire le nom du prog, un tiret puis une tabulation).


    On peut aussi declarer des alias globaux:
    # dans le .zshrc:
    alias -g e='emacs -nw'
    Et ensuite dans un term:
    $ sudo e test.sh -- (qui ouvre donc test.sh dans emacs console)



    Il y a aussi d'autres alias tres utiles, qui permettent d'executer un fichier avec le programme voulu en fonction de l'extension.
    # dans le .zshrc:
    alias -s pdf="xpdf"
    alias -s bz2="tar -xvjf"
    Et dans un term:
    $ ./mydoc.pdf -- (qui ouvre mydoc.pdf avec xpdf)
    $ ./myprog.tar.bz2 -- (qui detarre myprog.tar.bz2)



    Et il y a encore pas mal d'autres options sympas.
    Vraiment c'est le shell que je prefere.
  • # zsh-lovers

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

    Cette page est un must à lire avec plein d'astuces http://grml.org/zsh/zsh-lovers.html (dispo en page de manuel, et dans les dépôts de certaines distros).

    J'apprécie particulièrement l'option EXTENDED_GLOB:

    setopt extendedglob

    #effacer tous les fichiers sauf les .ogg
    rm -f *~*.ogg

    #effacer tous les .bak y compris dans les sous répertoires
    rm -f **/*.bak
    • [^] # Re: zsh-lovers

      Posté par . Évalué à 8.

      $ IFS=$’0; print -rl -- ${(Oau)${(Oa)$(cat file;echo .)[1,-2]}}

      Et après y'en a encore pour dire que perl c'est illisible... :-)
    • [^] # Re: zsh-lovers

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

      rm -f **/*.bak


      Avant avec bash il fallait faire très attention avec les "*" ; maintenant avec zsh il va falloir faire encore plus attention...
      • [^] # Re: zsh-lovers

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

        Mais si après avoir entré rm -f **/*.bak tu tapes [TAB] (avant de valider la commande, évidemment), il réalise l'expension en direct et sous tes petits yeux attentifs !

        C'est très pratique quand on veut vérifier que ce qu'il a trouvé correspond bien à ce qu'on pensait :)
    • [^] # Re: zsh-lovers

      Posté par . Évalué à 3.

      Le **/* et *~*.ogg... Hihi. Ca me rappelle la première version du A~B où B pouvait être vide... et où des devs, après une longue nuit de code, avaient voulu effacer les backups emacs avec **/*~ (à savoir, à l'époque, tout récursivement sauf rien...)

      Ca avait bougé dans la ML !
  • # la complétion dans bash ; eshell

    Posté par . Évalué à 3.

    Il est possible d'avoir la complétion automtique avancée dans bashrc :

    if [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
    fi

    Un autre shell très intéressant : le eshell. Le shell d'emacs écrit en
    emacs lisp. Son gros défaut est d'être encore très mal documenté. Ses
    avantages sont 1) sa portabilité 2) la possibilité de programmer en sh
    comme en emacs lisp.
    • [^] # Re: la complétion dans bash ; eshell

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

      Et depuis déjà quelque temps, le complètement automatique de bash est assez robuste. Exemple :

      urpmi xxx<tab> liste les paquetages commençant par xxx
      mplayer -<tab> liste les options de mplayer
      ssh <tab> liste des noms d'utilisateur
      ssh utilisateur@<tab> liste les adresses des machines déjà contactées
      make <tab> liste les cibles possibles

      Le complètement est aussi devenu un peu plus intelligent dans le sens où
      cd xxx<tab> ne listera que les répertoires
      mplayer -sub <tab> ne listera que les fichiers .sub et .srt
      rpm -ivh <tab> ne listera que les fichiers .rpm
      etc.

      Bien entendu ça n'est peut être pas aussi important que tout ce qu'est capable de faire zsh ; mais j'ai souvent entendu parler de zsh pour son complètement et les choses semblent bouger sur bash pour implémenter cela.
      • [^] # Re: la complétion dans bash ; eshell

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

        Le complètement intelligent, je n'aime pas trop, il suffit que ton fichier n'ait pas la bonne extension pour que tu ne puisse pas le trouver.

        Je ne sais plus pourquoi j'avais ce problème, mais par exemple, si tu veux dézipper un fichier ODT, tu ne peux pas (mauvaise exstension) ...

        file file.odt
        file.odt: Zip archive data, at least v2.0 to extract
        • [^] # Re: la complétion dans bash ; eshell

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

          Utilisateur de zsh, j'adore cette fonctionalité.

          Alors je viens de la tester sous bash, et je suis déçu. Effectivement, elle ne complète que sur ce qui lui convient.

          Zsh a la décence de compléter sur autre chose quand ça ne tombe pas juste.

          Sous bash :
          allergy@hali:/tmp/ic$ ls
          document.odt fichier.zip
          allergy@hali:/tmp/ic$ unzip d[TAB]
          ... Et il ne complète pas.

          Sous zsh, il constate qu'aucun fichier d*.zip n'est présent, alors il complète avec ce qu'il trouve, c'est à dire document.odt.

          Autre chose que j'aime : il complète également dans la partie "chemin" d'un hôte distant lors d'un scp. Très pratique, à condition d'utiliser les clés pour ssh :)

          Enfin, il permet de compléter en une seule fois une commande du type :
          tail -f /v/l/a/er[TAB] en tail -f /var/log/apache2/error.log.

          Il s'arrête éventuellement à la première ambiguïté et il y met le curseur :
          allergy@hali:~$ ls /tmp/ic/d*/*
          /tmp/ic/dir1/fichier /tmp/ic/dir2/fichier
          (d1 ou d2)

          allergy@hali:~$ cat /t/i/d/f[TAB] devient :
          allergy@hali:~$ cat /tmp/ic/dir / f (J'ai souligné la position du curseur).

          Il ne reste plus qu'à entrer "1" ou "2", et refaire [TAB].
          • [^] # Re: la complétion dans bash ; eshell

            Posté par . Évalué à 6.

            > Zsh a la décence de compléter sur autre chose quand ça ne tombe pas juste.

            Ce n'est pas le comportement par défaut apparemment, mais on peut configurer la completion de bash de la même façon

            complete -o comp-option

            comp-option may be one of:

            bashdefault: Perform the rest of the default bash completions if the compspec generates no matches.

            dirnames: Perform directory name completion if the compspec generates no matches.

            > il complète également dans la partie "chemin" d'un hôte distant lors d'un scp

            Dans bash aussi :)
        • [^] # Re: la complétion dans bash ; eshell

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

          J'ai aussi eu ce genre de problème quand j'ai voulu faire un cd vers un répertoire qui est en fait un lien symbolique si je me souviens bien (ou un truc du genre).

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: la complétion dans bash ; eshell

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

            chtitux@localhost ~/videos $ ls ../
            Display all 301 possibilities? (y or n)

            chtitux@localhost ~/videos $ ls ../
            chtitux/ user1/ user2/ jamendo/


            Surprenant ?! :)
            Réponse :

            chtitux@localhost ~ $ ls -l videos
            lrwxrwxrwx 1 chtitux users 14 mai 24 16:35 videos -> /home/jamendo/

            La complétion ne suit pas les liens, mais ls si :
            ~/videos $ ls ../ == /home/jamendo $ ls ../

            (bug ou feature, on m'a répondu feature sur #bash ...)
  • # Couper court au trolls

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

    A noter aussi que l'un des points génant pour l'adoption de zsh était le support de l'utf8 ce qui est résolu depuis les version "instable" 4.3 intégrées dans la plupart des distributions, le support n'est pas encore parfait (support uniquement dans le CLI et pas encore pour le code).

    A noter aussi que ZSH est capable d'émuler le comportement des shells existants : le bourne shell, CSH et KSH. Permettant dans beaucoup de cas, une migration des scripts existant avec peux de modification.

    Pour le faire dans le code : emulate -L ksh.
    Sinon faire un lien symbolique de /bin/zsh vers /bin/ksh par exemple et utiliser directement #!/bin/ksh dans son script.
  • # Il fut un temps ...

    Posté par . Évalué à 5.

    Ou j'étais tombé amoureux de Zsh, et je ne jurais que par lui, mais sur ma vielle marchine, il mettait 3-4 secondes a se lancer.

    Pendant toute une période, je me la suis même joué 95% console, donc le temps de démarrage de Zsh n'était pas prohibitif : comparé a X, 4 secondes n'étaient pas du temps perdu.

    Mais voilà, le temps a passé, j'ai changé de distribution (je nourrirais pas le troll en donnant des noms), les bureaux ont fait un bond incroyable en qualité, donc j'ai commencé a me logger en X systématiquement ... mais voilà, attendre 4 secondes a chaque fois ce n'était plus qu'une fois de temps en temps, c'était a chaque que j'ouvrais un console virtuelle, et c'est souvent. Dans le même temps, bash commençait a avoir un support de complétion plus que correct, sans compter que les configuration par défaut étaient toujours meilleure pour bash, donc voilà quoi, exit Zsh.

    Puis les années passent. Et aujourd'hui qu'en est il ? et bien je trouve la complétion de bash un peut restreinte, et franchement lente lorsqu'il s'agit de gros volumes (genre sur les paquets avec apt-get, et encore y'a eu de l'amélioration).
    Et surtout : je connais et maitrise bien plus le shell qu'a l'époque, j'ai fait de très gros progrès en lecture de docs, donc je suis bien plus a même de m'amuser avec les superbes fonctionalitées ci dessus et passer moins de temps configurer les détails ... sans compter que Zsh a sans doute fait bien des progrès en rapidité et puis ... j'ai changé de machine entre temps :)

    Et puis il y a un truc qu'il me manque cruellement : l'historique partagé entre les consoles, en live : trop le bonheur.
    • [^] # Re: Il fut un temps ...

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

      Voir histappend dans le man bash pour les historiques "partagés".
      • [^] # Re: Il fut un temps ...

        Posté par . Évalué à 2.

        merci :)
        • [^] # Re: Il fut un temps ...

          Posté par . Évalué à 2.

          rhhhaaa non, c'est pas ca que je voulais : partage "en live", c'est a dire que tu tape une commande, entrée, tu change de console, flèche du haut et tu as la commande que du viens de taper dans l'autre console !

          Mais effectivement, on peut utiliser cette commande pour sauvegarder l'historique a chaque validation de commande, et le charger a chaque fin de commande (je crois que bash permet ca). Mais j'ai peur pour les performances :)

          Mais j'ai regardé la doc de zsh, ce n'est pas une option intégrée dans zsh, étonnant puisque je l'avais compilé moi même.
    • [^] # Re: Il fut un temps ...

      Posté par . Évalué à 1.

      il ya un shell assez sympa pour la completion et la coloration syntaxique :
      http://roo.no-ip.org/fish/
  • # De l'utilisation de Zsh dans les scripts systèmes...

    Posté par . Évalué à 10.

    À l'heure où beaucoup de distributions Linux essaient de minimiser la durée du processus de démarrage, certains se demandent[2] pourquoi zsh n'est pas utilisé dans les scripts d'init à la place de bash ou dash pour éviter tous ces appels systèmes et gagner en temps d'exécution.


    On est tous d'accord sur le fait que le processus de démarrage de nos systèmes est beaucoup trop lent et gagnerait à être remanié pour le rendre plus rapide. Cependant, il s'agit là de savoir s'il y a besoin de rendre le processus de démarrage plus efficace, ou plus optimisé :
    - rendre le système de démarrage plus efficace serait possible en utilisant un démon de démarrage capable de parallèliser le lancement des scripts systèmes [1] ;
    - optimiser l'exécution des scripts systèmes serait possible en utilisant par exemple Zsh à l'intérieur des scripts systèmes, comme indiqué dans l'article, afin de limiter les appels systèmes.

    Je pense qu'on se trouve exactement dans le même débat que dans la news précédente sur l'utilisation de "champs de bits" en programmation [2]. Utiliser Zsh permettrait certes de gagner un peu de temps à l'exécution, mais celà reviendrait au même que d'utiliser des "champs de bits" pour optimiser un algorithme de type "tri bulle" (donc inefficace à la base).

    Le gain en vitesse par l'utilisation d'un démon parallèlisé serait donc beaucoup plus important, car cela reviendrait à traiter le problème à la base, et non optimiser un mauvais mécanisme (c'est pas en améliorant la bougie qu'on a inventé l'ampoule).

    Enfin je vois d'autres inconvénients à l'utilisation de Zsh dans les scripts systèmes :
    - dépendance supplémentaire : cela obligerait à installer Zsh sur tous les systèmes utilisant ces scripts optimisés, en plus du shell par défaut ;
    - scripts non-POSIX : les scripts systèmes utilisant le langage de script Zsh ne seraient plus compatibles POSIX, ce qui consisterait à un recul en matière de standardisation des systèmes Unix.
    - maintenance : les scripts (ba)sh ne sont peut-être pas optimisés, mais ils ont l'intêret d'être compris par l'ensemble des personnes ayant des connaissances en scripting. Combien de personnes connaissent le langage de script de Zsh ? Très peu.
    - migration : passer à Zsh nécessiterait de réécrire tous les scripts systèmes pour utiliser des fonctions Zsh et bénéficier des gains de performances.



    Bref, Zsh, ça fait un bail que je me dis qu'il faudrait que je trouve le temps de l'essayer pour une utilisation en tant que shell utilisateur, mais je pense que son utilisation n'est vraiment pas à recommander pour des scripts systèmes.
    Et pour les scripts non systèmes mais nécessitant un interprêteur efficace et un langage plus évolué que (ba)sh, des langages tels que Perl, Python ou Ruby me semblent plus adaptés.



    [1] : News DLFP : Qui va remplacer SysVinit ?
    http://linuxfr.org/2006/08/29/21258.html

    [2] : News DLFP : La quintessence des algorithmes bit à bit
    http://linuxfr.org/comments/751901.html#751901
    • [^] # Re: De l'utilisation de Zsh dans les scripts systèmes...

      Posté par . Évalué à 2.

      On est tous d'accord sur le fait que le processus de démarrage de nos systèmes est beaucoup trop lent et gagnerait à être remanié pour le rendre plus rapide.


      Bon, cette remarque m'étonnait, alors j'ai fait un test très con, mais très parlant.
      En mode "login automatique", j'ai mesuré le temps entre le moment ou je lance les OS depuis grub, et le moment où le pc est utilisable, c'est-à-dire quand il n'y a plus d'accès disque.
      Voilà les résultats:
      -Debian Etch + KDE 3.5: 43s
      -Windows XP SP2 : 1m45s

      Et c'est valable sur mes autres pc.
      Quand je suis passé à Linux, c'est vrai que le démarrage n'était pas super-rapide.
      Mais ça confirme ce que je pensais, ça s'est vachement amélioré, notamment avec udev/hotplug (et le noyau 2.6.15).
      Mes linux démarrent bien plus rapidement.

      Précision: mon XP est bien customisé (pas de msn qui se lance au démarrage, pas de winamp, services inutiles désactivés, etc).
      mon linux reconnaît bien mon wifi, ma webcam (Logitech QuickCam Communicate STX, très bien pour le manchot, même le micro marche), donc ce n'est pas biaisé.


      Après, c'est vrai que j'utilise une Debian, et ça doit être plus rapide qu'une distribution user-friendly, mais je ne connais que Debian.


      Voilà voilà, je vous invite à comparer, parce que ce que je peux lire m'étonne.
      • [^] # Re: De l'utilisation de Zsh dans les scripts systèmes...

        Posté par . Évalué à 8.

        >En mode "login automatique", j'ai mesuré le temps entre le moment ou je lance
        >les OS depuis grub, et le moment où le pc est utilisable, c'est-à-dire quand il n'y a
        > plus d'accès disque.

        J'espere pour toi que ton PC est utilisable aussi quand il y'a des acces disque !
        Evidemment ta methode de chronometrage est largement à l'avantage de linux : windows est pensé pour du desktop : il donne la main à l'utilisateur le plus rapidement possible et continue à démarrer des services en background. Apres ça, il fait son petit processus de reorg des fichiers sur disque pour accelerer le prochain boot. Mais il est utilisable bien avant ça. Enfin au moins chez moi et au boulot.

        Puisqu'il s'agit de donner des chiffres, je te donne les miens :
        - kde 3.5 avec boot parallele et un genre de readahead en autologin : 40 secs avant d'etre capable de lancer un konqueror pour faire office d'explorateur de fichier
        - windows xp sp2 sur la meme machine : 10 secs de moins pour lancer explorer.exe. Et c'est en comptant le temps que je tape mon login !

        Bien entendu je precise pas qu'il a fallu que je lutte à mort pour arriver à ces resultats avec linux ( generation de mes listes de fichiers perso pour le read ahead. Désactivation de certains services pour les relancer plus tard. Chronometrages en tout genre pour garder la meilleure soluce à chaque fois ). Sous windows, j'ai rien eu à faire.
        Une des différences c'est que windows ne boote pas avec des scripts. Les scripts c'est bien pour débugguer, c'est pratique pour diffuser des patchs et tout, mais quand il s'agit d'aller traquer la seconde, c'est moins chouette.
        • [^] # Re: De l'utilisation de Zsh dans les scripts systèmes...

          Posté par . Évalué à 3.

          J'espere pour toi que ton PC est utilisable aussi quand il y'a des acces disque !

          Oui, mais ça rame à mort, donc cela ne compte pas.

          Evidemment ta methode de chronometrage est largement à l'avantage de linux : windows est pensé pour du desktop : il donne la main à l'utilisateur le plus rapidement possible et continue à démarrer des services en background. Apres ça, il fait son petit processus de reorg des fichiers sur disque pour accelerer le prochain boot. Mais il est utilisable bien avant ça. Enfin au moins chez moi et au boulot.

          Pas chez moi. Windows n'est pas utilisable avant ce temps, pendant qu'il lance tous ses services, etc. Ce n'est pas le fait de voir la prairie qui permet de bosser. Au contraire, c'est exaspérant d'avoir l'impression que ton pc est prêt, alors qu'il ne l'est pas du tout.

          Puisqu'il s'agit de donner des chiffres, je te donne les miens :
          - kde 3.5 avec boot parallele et un genre de readahead en autologin : 40 secs avant d'etre capable de lancer un konqueror pour faire office d'explorateur de fichier
          - windows xp sp2 sur la meme machine : 10 secs de moins pour lancer explorer.exe. Et c'est en comptant le temps que je tape mon login !

          Mon kde est utilisable avant même que windows n'en soit au stade du login!

          Bien entendu je precise pas qu'il a fallu que je lutte à mort pour arriver à ces resultats avec linux ( generation de mes listes de fichiers perso pour le read ahead. Désactivation de certains services pour les relancer plus tard. Chronometrages en tout genre pour garder la meilleure soluce à chaque fois ). Sous windows, j'ai rien eu à faire.

          Cela m'étonne énormément. Quelle distribution utilises-tu? Tu utilises ntpdate, dhcp, tu recompiles ton noyau à chaque démarrage ;-) ?
      • [^] # Re: De l'utilisation de Zsh dans les scripts systèmes...

        Posté par . Évalué à 2.

        Autre comparaison, Mac OS X.3.9 et Ubuntu Edgy Eft sur un vénérable iBook G4 1,07 GHz.

        Mac OS : 37"
        Ubuntu : 1'36"

        D'un côté, Edgy est encore en développement et on peut estimer que les choses vont s'améliorer, de l'autre, edgy inclut déjà certaines optimisations de vitesse de boot…

        Il est vrai aussi, que Panther est spécifiquement conçu pour ces machines quasiment : il n'a même pas de support 64bits, et encore moins d'autre architectures, sans parler de milliers de modèles de PC différents…

        Reste qu'en tant qu'utilisateur, je sens bien la différence de vitesse de boot.

        La vitesse d'extinction (que tout le monde oublie alors qu'elle compte bien dans le redémmarage, opération que j'effectue régulièrement) est aussi à l'avantage de Panther, quoiqu'Ubuntu ait fait d'énorme progrès en la matière avec Edgy…
      • [^] # Re: De l'utilisation de Zsh dans les scripts systèmes...

        Posté par . Évalué à 1.

        > Précision: mon XP est bien customisé (pas de msn qui se lance au démarrage, pas de winamp, services inutiles désactivés, etc).

        Je suis tout de même très sceptique sur la "customisation" de ton XP.

        J'ai réinstallé XP pro sur mon pc la semaine dernière, en désactivant les trucs inutiles activés de base (services inutiles, msn, etc...).
        Mon PC met moins de 40 secondes à booter sous XP, depuis le moment où je presse l'interupteur, jusqu'à l'invite de login, en passant par le grub (et la sélection d'OS que je fais manuellement).

        Une fois à l'invite de login, le tout est quasiment totalement chargé, le temps que j'entre mon login, que je valide et que le bureau s'affiche, tout est chargé, près à l'usage.
        Donc XP en lui même doit mettre pas plus de 40 secondes à se charger totalement.
        Et ma machine à 5 ans, donc c'est pas non plus une bete de coursse.

        Linux à de gros avantages sur windows.... mais au niveau démarage, pour le moment je donne plutot windows gagnant.
        • [^] # Re: De l'utilisation de Zsh dans les scripts systèmes...

          Posté par . Évalué à 1.

          Vous êtes bien gentils avec vos mesures de temps, du genre "moi mon xp démarre en 40 sec, alors si le tiens met 1m30, c'est que t'es un naze" (je résume ;-) ). Mais sans connaître la config matériel on ne peut rien en tirer... Un PIII avec 256Mo de RAM démarrera fatalement plus lentement qu'un Athlon 64 de la mort qui tue avec 2Go, non?
          Enfin, pour apporter ma petite contribution, sur mon portable (P4M 1,6GHz, 512Mo, HD 80Go/5400tr/min), je dirais que XP arrive plus vite sur l'écran de login que Linux/Debian testing, mais que Gnome est plus vite opérationnel que le bureau XP, qui apparaît certe très vite mais reste inutilisable très longtemps!
        • [^] # Re: De l'utilisation de Zsh dans les scripts systèmes...

          Posté par . Évalué à 3.

          bien moi si je fais un comparatif,

          je redemarre XP 1 fois par jour minimum,

          alors que ma gentoo ....
          $ uptime
          13:09:37 up 17 days, 14:55, 4 users, load average: 0.71, 0.18, 0.08
          noyau (2.6.17-gentoo-r4) oblige ....

          donc demarrage gentoo + KDE plus d'une minute tous les mois

          et XP 40 secondes tous les jours ....

          choisissez votre camps !
          • [^] # Re: De l'utilisation de Zsh dans les scripts systèmes...

            Posté par . Évalué à 1.

            et ensuite on compare vos factures EDF \o/

            (ah, et comparer des temps de boot, c'est assez idiot de partir du moment où on pousse le bouton on/off, on conseille souvent de compter à partir du chargement du bootloader, soit après le POST (Power-on self-test))
        • [^] # Re: De l'utilisation de Zsh dans les scripts systèmes...

          Posté par . Évalué à 2.

          J'ai réinstallé XP pro sur mon pc la semaine dernière

          Ah.
          On en reparlera quand le système de fichier sera fragmenté, que la base de registre sera plus bordélique que la chambre des mes copiaules américains, etc. As-tu un antivirus, ton XP est-il à jour (bah ouais, le SP2 il te plombe bien la machine)? Tu peux répondre que ce n'est pas indispensable, mais là je te dirai que cela fait parti de WIndows, étant donné qu'ils conseillent fortement d'avoir un antivirus (y'a qu'à voir la tronche que fait le centre de sécurité sinon), et que les machines sans service pack 2 ne seront bientôt plus supportées. Démarrer un windows XP à jour sur un pc vieux de 5 ans en 40 secondes est totalement impossible.
        • [^] # Re: De l'utilisation de Zsh dans les scripts systèmes...

          Posté par . Évalué à 2.

          Tu as un anti-virus et un firewall lancé par défaut ?
    • [^] # Re: De l'utilisation de Zsh dans les scripts systèmes...

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

      rendre le système de démarrage plus efficace serait possible en utilisant un démon de démarrage capable de parallèliser le lancement des scripts systèmes

      si on en croit la personne qui a travaillé sur le projet SoC pour l'amélioration de la vitesse de boot de debian ( http://bootdebian.blogspot.com/ ) , le gain en parallèlisant les scripts est très faible (environ 4s ).

      optimiser l'exécution des scripts systèmes serait possible en utilisant par exemple Zsh à l'intérieur des scripts systèmes, comme indiqué dans l'article, afin de limiter les appels systèmes.
      Ce qui prend surtout du temps (AMA) c'est tout simplement l'exécution du service en lui même, le service qui peut avoir à lire des fichiers de configurations, checker des données, etc ...

      dépendance supplémentaire : cela obligerait à installer Zsh sur tous les systèmes utilisant ces scripts optimisés, en plus du shell par défaut
      c'est pas vraiment un argument, zsh doit peser à peine 500 ko, sachant que dans les paquets de base d'une majeure partie, tu as perl qui por une installation minimal te prendra beaucoup plus de place.

      les scripts systèmes utilisant le langage de script Zsh ne seraient plus compatibles POSIX, ce qui consisterait à un recul en matière de standardisation des systèmes Unix
      c'est indéniable, ceci dit, quand on voit upstart qui sera un espèce de démon fourre tout (init, cron, udev, inetd?) où on rompt avec la tradition "faire une chose, mais la faire correctement", on peut très bien envisagé de faire une rupture complète et essayer de faire un des scripts d'init en zsh avec une bibliothèque de fonction zsh pour remplacer les outils tels que sed, cut, grep, awk. C'est une idée mais ça peut être intéressant si les résultats sont là.

      maintenance : les scripts (ba)sh ne sont peut-être pas optimisés, mais ils ont l'intêret d'être compris par l'ensemble des personnes ayant des connaissances en scripting. Combien de personnes connaissent le langage de script de Zsh
      si on raisonne comme ça, on serait toujours à faire du basic, après si les dev ne veulent pas évoluer, apprendre de nouvelles choses, je ne donne pas cher de leur avenir dans l'informatique dans 10 ans au train où ça évolue. Après, zsh à une doc et comme signalé dans l'article il y'a des wiki, des listes de diffusions, des canaux irc, etc ...


      migration : passer à Zsh nécessiterait de réécrire tous les scripts systèmes pour utiliser des fonctions Zsh et bénéficier des gains de performances
      pas insurmontable à mon avis...

      Et pour les scripts non systèmes mais nécessitant un interprêteur efficace et un langage plus évolué que (ba)sh, des langages tels que Perl, Python ou Ruby me semblent plus adaptés.

      je suis pas d'accord, je suis utilisateur des langages de scripts (non shell) que tu sites et il est à mon avis souvent bien plus rapide d'utiliser un script shell pour certains tâches.

      M.
  • # Ma fonctionnalité préférée : l'invite sensible au code de retour

    Posté par . Évalué à 2.

    Un exemple de fonctionnalité que j'adore dans zsh : il est possible de régler l'invite pour qu'elle affiche le code de retour de la dernière commande ; de plus, on peut spécifier des conditions dans le réglage de l'invite, ce qui fait qu'on peut avoir, par exemple, une invite verte en cas de succès de la dernière commande et rouge sinon. Ainsi on repère du premier coup d'oeil si une commande a réussi ou non (pratique pour les compilations).

    Voici un exemple de configuration mettant cela en oeuvre :

    # Début de code à insérer dans ~/.zshrc :

    # Pour pouvoir utiliser des couleurs nommées :
    autoload -U colors
    colors

    # Invite sensible au code de retour :
    PS1="%(?:%{$fg[green]%}:%{$fg[red]%})%n@%m (%?) %~ %# %{$reset_color%}"

    # Fin du code à insérer.

    La syntaxe pour la condition est : %(variable:si_vrai:sinon)

    La variable du code de retour est le point d'interrogation.
  • # Le chemin du changement

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

    Si comme beaucoup, vous avez écrit des dizaines, voire des centaines de scripts shell, le changement d'un interpreteur, nécessite souvent de revoir certaines parties des scripts en question. Petit exemple :

    Le bout de script ksh :

    echo "Est-ce que tu aimes KoRN : \c" ?
    read REP
    echo "Votre réponse est : $REP"

    s'écrit avec bash :

    echo -e "Est-ce que tu aimes KoRN : \c" ?
    read REP
    echo "Votre réponse est : $REP"

    Il s'agit donc de choisir les scripts qui sont appelés a être utilisés encore longtemps en tant que candidats au changement. Dans ce cas, comme dans celui du partage de vos scripts, il est nécessaire d'avoir plusieurs shells installés.

    Il n'y a qu'un seul shell standard qui est installé sur tous les unix : sh. C'est avec lui que vous pourrez, avant de lancer votre script principal, vérifier
    quel shell est disponible et de sortir le cas échéant une erreur qui sera plus parlante que le fatidique : /bin/zsh: bad interpreter.

    Fun : http://www.kornshell.com/fun/
  • # il est rapide, léger

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

    hum.

    Non zsh est plutôt lent et lourd, mais il fait beaucoup de choses.
  • # chez moi ca bug

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

    J'utilise zsh sous ddebian sarge en stable, et je rencontre un bug très chiant (que j'avais déjà sous woody) c'est la touche "début" (si si, celle en forme de flèche qui pointe nord-ouest).
    Achaque fois que je m'en sert pour revenir au début du prompt (typique pour ajouter sudo) ca fait planter la ligne... Ultra chiant...
    • [^] # Re: chez moi ca bug

      Posté par . Évalué à 1.

      chezmoicamarche (pratique d'ailleurs je connaissais pas :P) qu'elle version de ZSH utilise tu? si tu l'as installé avec le paquet zsh essaye le paquet zsh-beta, plus récent.
    • [^] # Re: chez moi ca bug

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

      >Achaque fois que je m'en sert pour revenir au début du prompt (typique pour ajouter sudo) ca fait planter la ligne... Ultra chiant...

      Alors que tu serais un vrai emacsien tu ferais Ctrl-a ;-)
    • [^] # Re: chez moi ca bug

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

      je rencontre un bug très chiant c'est la touche "début"

      As-tu essayé :

      C-a (Déplacement au debut de la ligne courante)
      C-e (Déplacement en fin de ligne courante)

      Feature : Ça marche aussi sous emacs :)
      • [^] # Re: chez moi ca bug

        Posté par . Évalué à 1.

        "ça marche aussi sous Emacs"

        Normal c'est les raccourcis d'Emacs ;)
        Il est également possible de passer en mode vi (du moins sous bash) :
        set -o vi
    • [^] # Re: chez moi ca bug

      Posté par . Évalué à 1.

      Si ce n'est déjà fait, on peut définir toute une série de touches presque automatiquement.
      Il suffit de rajouter au début de son .zshrc :

      autoload zkbd
      zkbd


      Ensuite on lance son terminal où zsh va y poser plusieurs questions et demander d'appuyer sur quelques touches (F1 à F12, suppr, home, end, haut, bas, etc ...)
      Ensuite il suffira de lire ce qui est dit à la fin pour finir la configuration.
  • # et à propos

    Posté par . Évalué à 1.

    la licence ? du BSD ?
    • [^] # Re: et à propos

      Posté par . Évalué à 1.

      C'est de type BSD :


      The Z Shell is copyright (c) 1992-2004 Paul Falstad, Richard Coleman,
      Zoltán Hidvégi, Andrew Main, Peter Stephenson, Sven Wischnowsky, and
      others. All rights reserved. Individual authors, whether or not
      specifically named, retain copyright in all changes; in what follows, they
      are referred to as `the Zsh Development Group'. This is for convenience
      only and this body has no legal status. The Z shell is distributed under
      the following licence; any provisions made in individual files take
      precedence.

      Permission is hereby granted, without written agreement and without
      licence or royalty fees, to use, copy, modify, and distribute this
      software and to distribute modified versions of this software for any
      purpose, provided that the above copyright notice and the following
      two paragraphs appear in all copies of this software.

      In no event shall the Zsh Development Group be liable to any party for
      direct, indirect, special, incidental, or consequential damages arising out
      of the use of this software and its documentation, even if the Zsh
      Development Group have been advised of the possibility of such damage.

      The Zsh Development Group specifically disclaim any warranties, including,
      but not limited to, the implied warranties of merchantability and fitness
      for a particular purpose. The software provided hereunder is on an "as is"
      basis, and the Zsh Development Group have no obligation to provide
      maintenance, support, updates, enhancements, or modifications.
  • # Commentaire supprimé

    Posté par . Évalué à -3.

    Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Re: ca sert a rien

      Posté par . Évalué à 1.

      Bah utilise eshell ou scsh et écrit des scripts en Emacs Lisp ou en
      Scheme ;)

      Et oublie Monad ... :D
  • # Défaut: unicode

    Posté par . Évalué à 2.

    J'utilisais zsh, qui soit dit en passant n'est pas si léger, j'ai toujours trouvé bash plus rapide sur les petites config, mais je l'ai provisoirement abandonné quand je suis passé à des distributions linux UTF8 par défaut... Et c'est bien le gros problème actuel par rapport à bash. Ce problème est en cours de résolution et les version devel de zsh ont maintenant un support utf8 partiel.
    • [^] # Re: Défaut: unicode

      Posté par . Évalué à 1.

      chic, il sera encore moins léger...
    • [^] # Re: Défaut: unicode

      Posté par . Évalué à 1.

      +1, j'adore zsh, sur des machines récentes c'est un vrai bonheur à utiliser !
      mais depuis mon passage en utf8 c'était devenu un calvert...
      donc je suis retombé à Bash.

      Content d'apprendre qu'en devel l'utf8 avance mais depuis le temps je trouve l'évolution un peu lente (c'est pas un reproche, pas taper !)

      enfin je me souviens souvent avoir lu des réprimandes avec des .zshrc mal configurés qui empêchent root et les user de se logguer...
      et bien je tiens à dire que c'est largement faisable avec bash aussi, j'en ai pour preuve ma propre experience :p
  • # Prompt Zsh

    Posté par . Évalué à 1.

    Je profite de cette news pour poser une question sur le prompt Zsh.

    En faisant des recherhes sur le net je n'est pas réussi à trouver le caractère qui correspont au "\n" sous bash et qui permet de revenir à la ligne pour que celle-ci ne soit pas trop grande ?

    Quelqu'un pour aider ?

    Merci.
    • [^] # Re: Prompt Zsh

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

      Bah, ta touche Enter :)

      Exemple chez moi, où j'affiche sur la ligne au dessus du prompt, le code de retour de la commande précédente s'il est différent de 0.

      _exitcode="%(?::${C_BRED}[ %? ]${C_NO}
      )"


      Oui, le retour à la ligne est simplement balancé dedans :)
      • [^] # Re: Prompt Zsh

        Posté par . Évalué à 1.

        et le symbole/variable etc.. exact pour ce retour à la ligne quel est-il ?
        • [^] # Re: Prompt Zsh

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

          À ma connaissance, il n'existe pas, mais il est très facile de créer une variable que tu peux réutiliser par la suite, si tu n'as pas envie d'encombrer certains définitions :

          allergy@hali:~$ ENDL="
          dquote> "
          allergy@hali:~$ echo "Une et${ENDL}Deux lignes"
          Une et
          Deux lignes
  • # scripts d'init en ZSH

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

    Salut,

    sur notre distrib Formilux, on utilisait ZSH il y a 5 ans pour tous les scripts d'init et de gestion des services. Triple avantage :
    - il était ultra rapide (parser des fichiers de confs en ZSH était presque aussi rapide qu'en awk)
    - il est bien plus compact que bash, car certainement mieux écrit
    - il gère très bien les tableaux, ce qui est pratique pour stocker des paramètres de services

    Seulement, on a souvent besoin de débugger des scripts de démarrage, surtout lorsqu'une distrib est jeune. Il est alors indispensable d'avoir le même shell que celui des scripts, car on a vite fait de faire des tas de copiers-collers de commandes partielles pour voir ce qui merde.

    Or, il s'est avéré qu'en production, les clients habitués à KSH étaient complètement perdus avec ZSH, en particulier avec le mode de complétion qui affiche tout sous le curseur et qui fait remonter le prompt (assez déroutant, et on n'a jamais trouvé comment le remettre comme bash). Quelques autres différences majeures que je n'ai plus en tête leur faisaient penser à des gadgets plus qu'à des serveurs sérieux.

    On est alors revenus à du bash bien plus classique comme shell par défaut, et on a vite compris que les scripts de démarrage allaient devoir être convertis très vite, d'une part parce que ça prenait plein de place d'avoir 2 shells (300 ko chacun) et d'autre part pour la raison de debugging évoquée ci-dessus.

    Cependant, je persiste à penser que pour certains usages spécifiques (développement de programmes d'installation et/ou de configuration, génération de règles de firewalls, etc...), ce shell est absolument fabuleux et vraiment très rapide. On dispose aussi d'accès réseaux très puissants avec multiplexage de sockets, ce qui est bien sympa pour des outils d'install.

    Voilà, je continue de soutenir pleinement ce shell de très grande qualité, même si je reconnais m'en servir très rarement de nos jours.

    --Willy

Suivre le flux des commentaires

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