Sortie de zsh 4.3.5 et 4.2.7

Posté par  (site web personnel) . Modéré par rootix.
Étiquettes :
2
3
fév.
2008
Ligne de commande
Deux nouvelles versions de l'interpréteur de commandes zsh viennent de sortir.
La première (4.2.7) concerne la branche stable et la seconde (4.3.5) concerne la branche de développement.

La nouvelle version stable apporte - par rapport à la vieillissante branche 4.2 - essentiellement des corrections de bugs et la mise à jour des fonctions de complétion.

La version dite instable apporte de nouvelles fonctionnalités et ses habituelles mises à jours des fonctions de complétion. Elle est en réalité d'une grande stabilité et est déjà distribuée dans la plupart des distributions GNU/Linux et Unix libres, comme version zsh par défaut.

Pour rappel zsh est un interpréteur de commandes libre sous licence zsh (comparable à la licence BSD), disposant de fonctionnalités de complétion programmables et avancées, offrant des modules haut niveau pour la programmation : fonctions TCP/IP, support des REGEX, fonctions FTP, fonctions de manipulations de dates et pouvant émuler le comportement d'autres interpréteurs de commande : ksh, bash, ash, csh. Alors que la version 4.3 apportait déjà beaucoup de nouveautés parmi lesquelles :
  • Support de l'unicode ;
  • Le support des exceptions pour la programmation de scripts : throw/catch ;
  • La comparaison temporelle entre les fichiers utilisant les timestamp permettant ainsi une précision à la nanoseconde au lieu de la seconde ;
  • l'amélioration des compatibilités avec les shells POSIX et bourne.

La version 4.3.5 en rajoute beaucoup elle aussi :
  • Nouveau module zsh/curses Permettant la programmation native d'interface graphiques utilisant la bibliothèque curses/ncurses ;
  • Amélioration du modules zsh/datetime qui permet la gestion du temps et des dates avec les fonctions strftime et la variable d'environnement $EPOCHSECONDS ;
  • Nouvelle fonction calendar similaire à la fonction unix éponyme, mais avec beaucoup plus de fonctionnalités ;
  • La notion de "feature" permettant au chargement de renommer certaines fonctions zsh. Par exemple zsh fournit une module zsh/stat qui améliore et remplace la fonction stat, pour pouvoir utiliser les deux fonctions conjointement, il suffit de charger le module de la façon suivante :
    zmodload -F zsh/stat b:zstat
    ainsi la fonction stat pure zsh s'appellera zstat et non stat.

Aller plus loin

  • # Des exemples ?

    Posté par  . Évalué à 2.

    Nouveau module zsh/curses Permettant la programmation native d'interface graphiques utilisant la bibliothèque curses/ncurses ;

    Tu as des exemples de codes ? Qu'est-ce que ça peut donner dans la "vie de tous les jours" ?

    J'ai toujours eu une certaine attirance de ZSH mais toutes ces extensions étant purement zsh, point de salut lorsqu'on doit repasser à KSH ou même BASH. C'est dommage :/

    • [^] # Re: Des exemples ?

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

      Voici un exemple de code :

      curses_test () {
      win=toto
      zmodload zsh/curses
      zcurses init
      zcurses addwin $win 10 20 1 1
      zcurses border $win
      zcurses move $win 4 2
      zcurses string $win "HelloWorld !!"
      zcurses refresh $win
      sleep 5
      zcurses delwin $win
      zcurses end
      }

      curses_test

      La doc zsh est très bien foutu, complète et disponible sous forme pdf, html, man ou GNU info.
      Le site n'est pas encore à jour concernant les dernières versions de la doc. Mais les distributions distribuent la doc à jours avec zsh (c'est au moins le cas avec gentoo - le use doc -)

      Sinon le problème que tu évoques est identique quand tu code pure bash ou pure ksh, tu ne peux pas l'utiliser sur d'autres shells, (sauf zsh grace aux fonctions emulate)

      Si tu veux que ton code marche partout, il suffit de faire du code POSIX.

  • # feature

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

    Est-ce que la notion de feature permet aussi de ne charger qu'une fonction d'un module ? À la 'from module import fonction as mafonction' en python ? Avec datetime, il y a une seule fonction zsh que j'utilise et je préfère garder les programmes classiques sinon (sans doute un mauvais choix en performances, mais bon)

    Sinon, il y a un repository de scripts zsh qui font tout et le café quelque part ? J'aurais deux-trois trucs qui peuvent intéresser des gens à soumettre. Et j'aimerais voir comment les autres programment en zsh...

    • [^] # Re: feature

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

      Pour les repository tu as zshwiki : http://zshwiki.org/home/ qui peut faire l'affaire.
      Pour la notion de feature je ne sais pas du tout, mais concernant le module datetime, il n'y a qu'une seule fonction (si je ne me trompe pas) : strftime, et une variable d'environnement, donc tu n'as pas besoin de ne charger qu'une partie du module.

      Pour la programmation, moi je m'efforce quand je fait du zsh, de ne faire que du pure zsh (cad pas de grep cat sed ou autre). Sinon je ne fait que du POSIX, donc pas spécifique zsh (mais je pousse le posix y compris dans les commandes associées awk, sed par exemple, pas d'extention GNU, sinon ce n'est plus portable).

      Pour plus d'informations sur zmodload :
      man zshbuiltins section zmodload, ou
      http://baptux.free.fr/zsh/zsh_17.html recherche zmodload (plus précisément la partie -F)

      • [^] # Re: feature

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

        Pas d'extensions GNU... C'est dommage car GNU devient la référence car POSIX n'a pas su évoluer depuis 15 ans. C'est ainsi que POSIX donne les tailles de disques en blocs de 512 octets car cela correspondait à la taille des blocs de données de l'époque.
        Il y a quelques années, j'ai vu un Unix commercial (IBM ?) qui se disait conforme GNU.
        Ceci est le premier exemple qui m'est venu à l'esprit Il est assez facile d'en trouver d'autres. Les extensions GNU n'ont pas été faites pour le fun ou des raisons commerciales mais seulement pour répondre à de vrais besoins des utilisateurs.

        • [^] # Re: feature

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

          Le fait est que actuellement, les extensions GNU ne sont pas portable, elles sont disponible quasi uniquement sous les variantes de linux.
          Je travaille régulièrement sur des AIX, HP-UX, Solaris, Linux et BSD, récents ou pas, donc je ne peux pas me fier aux extensions GNU, donc je fais du POSIX quand je veux des scripts portables. Sinon je fais du zsh (comme j'installe zsh sur la majeure partie de mes serveurs, ça devient tout aussi portable et beaucoup plus agréable à utiliser).

          Exemples de petites choses qui ne sont pas portable : cp -a (toujours utiliser cp -dpPR à la place) sed -i, plein de fonctions gawk (que l'on ne retrouve ni dans mawk, ni dans nawk) etc.

          • [^] # Re: feature

            Posté par  . Évalué à 0.

            Si tu prends le temps d'installer zsh sur tous tes serveurs, tu peux alors bien prendre le temps d'installer les exécutables GNU dans /usr/local pour remplacer avantageusement les vieux awk, sed etc...

            Sinon oui effectivement, il vaut mieux faire du POSIX de base pour être le plus portable possible.

            • [^] # Re: feature

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

              D'une nom car il y a une grosse différence entre poser les outils gnus : gawk, gsed, coreutils, etc. donc plein de packages et une seul et unique package zsh (qui est bien souvent disponible dans les packages officiels)

              De plus les plateformes de prod sont installés avec des socles minimum, donc pas de rajout (pas de zsh non plus) donc mes scripts qui iront en prod sont en pure POSIX. Ceux en zsh, sont ceux qui me facilitent la vie et ne vont pas en prod.

              • [^] # Re: feature

                Posté par  . Évalué à -1.

                Ouais enfin c'est pas la mort d'installer un ou plusieurs package, généralement on fait un script de déploiement et hop ça prend le même temps, donc l'argument ne tient pas.

                Quant aux socles minimum installés en prod, tu dis qu'il n'y a pas de rajout possible, sauf que désolé de te contre-dire encore une fois, mais pour mettre en prod une machine (là où je bosse par exemple) il y a toujours des rajouts, je pense notamment aux outils d'instrumentation, logiciels de sauvegarde (TSM etc...), menu d'exploit etc...ces rajouts font l'objet d'un packaging standardisé et s'installe automatiquement après le déploiement de l'OS, c'est ce que l'on appelle l'industrialisation des infrastructures.

                Donc si ton besoin est de disposer de zsh only, alors remonte ton besoin aux équipes qui gèrent ça chez toi pour l'intégrer dans un master, si ce n'est pas possible alors ok pour le POSIX

                • [^] # Re: feature

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

                  Sauf que l'on pas toujours le choix de la fourniture en prod, de plus je ne vois pas l'intérêt de forcer l'installation de packages GNU ou zsh en prod, puisque les scripts POSIX font très bien l'affaire, et que je suis certain de la portabilité de ceux-ci. De plus je suis certains de la réutilisabilité de mes scripts de prod par n'importe qui, qu'il soit de la vieille école (formé sur des vieux unix) ou de jeunes formés sous linux. Bref je fait du POSIX car c'est propre et standard !!!

                  En ce qui concerne mes scripts ZSH ce sont des scripts qui me concerne moi et qui n'iront jamais en prod. Ils me facilitent la vie dans la gestion de mes machines au quotidien.

                  De plus en prod, tu n'as pas toujours la main sur les socles de productions, il y a beaucoup de plate-forme livré clefs en main, ou tu ne peux pas demander le rajout de composant GNU ou zsh ou autres que ceux décidés par le fournisseur, en recette ou en dev ce n'est pas la même chose, c'est généralement plus souple (quoique pas toujours). Donc pour résumer ce que je disais :
                  POSIX pour la portabilité, réutilisabilité, zsh pour me faciliter la vie.

                  PS: Dans certains contexte très rares, j'ai des scripts zsh en prod.

          • [^] # Re: feature

            Posté par  . Évalué à 2.

            Je travaille régulièrement sur des AIX, HP-UX, Solaris, Linux et BSD, récents ou pas, donc je ne peux pas me fier aux extensions GNU, donc je fais du POSIX quand je veux des scripts portables.

            J'utilise a peu pres les memes OS (aujourd'hui AIX, HP-UX et Linux, avant Solaris). Sur les plateformes de developpement, j'installe systematiquement un certain nombre d'outils GNU, en particulier gmake et bash, parce qu'entre se limiter au plus petit denominateur commun des outils parfois antédiluviens fournis par l'OS, et installer une version plus agréable et disponible partout, le choix est vite fait.

            Sur les plateforme de prod, par contre, c'est du brut de constructeur, donc les scripts doivent etre portables...

  • # Slackware

    Posté par  . Évalué à -1.

    Est-ce installable sur SlackWare (la meilleure distribution) ?

    • [^] # Re: Slackware

      Posté par  . Évalué à 2.

      Pourquoi ça ne s'installerait pas ? La slackware 12.0 fournit pour le moment zsh 4.3.2. La manière la plus rapide de se faire un paquet avec la dernière version, c'est d'avoir src2pkg, de télécharger les sources, et zou une petite commande te donne un beau paquet tout prêt : $ src2pkg zsh-4.3.5.tar.bz2

      M'enfin je pense qu'un paquet officiel sortira bientôt. Slackware, la meilleure distribution, oui, mais de ceux qui l'ont choisie. On n'est pas encore vendredi ^^

    • [^] # Re: Slackware

      Posté par  . Évalué à 1.

      Oui, je me suis fait le slackbuild qui va bien mais en gros c'est archi simple: ./configure; make && make install

      Par contre, il y a un truc qui m'échappe. Si je change mon login pour zsh, la session ne dure pas plus de 1/100000 eme de seconde :/

      (chsh -s /bin/zsh xma => /bin/zsh n'est pas un shell valide)

      • [^] # Re: Slackware

        Posté par  . Évalué à 1.

        Bon je sais pourquoi :) J'ai omis d'ajouter zsh à la liste des possibles dans /etc/shells ;)

        Ca fonctionne maintenant.

        • [^] # Re: Slackware

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

          Pouquoi ne pas avoir pris le slackbuild officiel ( ftp://ftp.slackware.at/slackware_source/ap/zsh/zsh.SlackBuil(...) ) pour le mettre à jour au moins tu était sûr de ne rien oubliés (/etc/shells).

          • [^] # Re: Slackware

            Posté par  . Évalué à 1.

            Parce que je n'y tout simplement pas pensé :) Et surtout je ne savais même pas qu'il était dans la slack (j'utilise les fichiers tags pour mes installations auxquels je ne touche jamais).

            Mais évidemment, je vais le reprendre et le soumettre au Sieur.

            Maintenant je vais tenter le douloureux et très lent (ré)apprentissage du zsh, pour voir si je peux (re)vivre avec.

Suivre le flux des commentaires

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