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.
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).
Aller plus loin
- ZSH Extended Network (61 clics)
- Gestion du projet ZEN (34 clics)
# ZEN c'est zen !
Posté par Bruno Bonfils (site web personnel) . Évalué à 5.
% 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 alexissoft . É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 Bapt (site web personnel) . Évalué à 0.
[^] # Re: ZEN c'est zen !
Posté par alexissoft . Évalué à 1.
[^] # Re: ZEN c'est zen !
Posté par Bapt (site web personnel) . Évalué à 2.
[^] # Re: ZEN c'est zen !
Posté par alexissoft . Évalué à 1.
[^] # Re: ZEN c'est zen !
Posté par Bapt (site web personnel) . Évalué à 3.
[^] # Re: ZEN c'est zen !
Posté par Bruno Bonfils (site web personnel) . Évalué à 2.
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 zebra3 . Évalué à -3.
# 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 Bapt (site web personnel) . Évalué à 4.
[^] # Re: ZEN c'est zen !
Posté par zebra3 . Évalué à 2.
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.
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 Bruno Bonfils (site web personnel) . Évalué à 2.
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 cram51 . Évalué à 1.
On est pourtant pas encore vendredi ...
[^] # Re: Vendredi
Posté par 2PetitsVerres . Évalué à 10.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Vendredi
Posté par Ph Husson (site web personnel) . Évalué à 0.
[^] # Re: Vendredi
Posté par Bruno Bonfils (site web personnel) . Évalué à 1.
Mais j'avoue, le concept est quand même super intéressant..
[^] # Re: Vendredi
Posté par zebra3 . Évalué à 1.
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 Pierre Jarillon (site web personnel) . Évalué à 1.
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 Bapt (site web personnel) . Évalué à 5.
# Gestionnaires de paquetage
Posté par nojhan (site web personnel, Mastodon) . Évalué à 3.
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 Bruno Bonfils (site web personnel) . Évalué à 2.
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 Bruno Bonfils (site web personnel) . Évalué à 3.
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 Bapt (site web personnel) . Évalué à 3.
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 nojhan (site web personnel, Mastodon) . Évalué à 3.
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 Thierry Thomas (site web personnel, Mastodon) . Évalué à 5.
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 zyphos . Évalué à 1.
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 lrbabe . Évalué à 1.
En plus court et en onomatopée : "Gné ?"
[^] # Re: Le tout en pur zsh
Posté par Bapt (site web personnel) . Évalué à 5.
[^] # Re: Le tout en pur zsh
Posté par Dup (site web personnel) . Évalué à 6.
[^] # Re: Le tout en pur zsh
Posté par Bruno Bonfils (site web personnel) . Évalué à 3.
[^] # Re: Le tout en pur zsh
Posté par Kangs . Évalué à 2.
Tu viens de comprendre à quoi servent les normes et notamment posix !
[^] # Re: Le tout en pur zsh
Posté par Bruno Bonfils (site web personnel) . Évalué à 5.
Mais merci de ton illumination extraordinaire !
[^] # Re: Le tout en pur zsh
Posté par Sylvain Sauvage . Évalué à 6.
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 Adrien . Évalué à 5.
$ 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 Bruno Bonfils (site web personnel) . Évalué à 1.
[^] # Re: [HS] question sur Zsh
Posté par Bapt (site web personnel) . Évalué à 2.
[^] # Re: [HS] question sur Zsh
Posté par HoloAddict (site web personnel) . Évalué à 2.
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 태 (site web personnel) . Évalué à 5.
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 Adrien . Évalué à 2.
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 HoloAddict (site web personnel) . Évalué à 2.
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 태 (site web personnel) . Évalué à 5.
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 mornik . Évalué à 1.
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 태 (site web personnel) . Évalué à 2.
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.
Est-ce possible ? Ou il n'y a que tcsh pour cette fonction ?
Merci.
[^] # Re: Historique zsh
Posté par Farzad FARID (site web personnel) . Évalué à 6.
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.
[^] # Re: Historique zsh
Posté par poiuy . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.