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.
![[en]](../images/en.png)
zsh.org (528 hits)-
Annonce 4.2.7 (122 hits)
-
Annonce 4.3.5 (170 hits)
-
ZSH lovers (355 hits)
-
ZSH sur dmoz (151 hits)
> Lire la dépêche (18 commentaires, moyenne: 2,7).
Vous avez demandé le commentaire #901476.
Run by 
Cette page a été générée par Templeet en 0.0711s (dont 0.0055 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
feature
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
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
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
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
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
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
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
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
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...