dimanche 05 octobre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: À la (re)découverte de Zsh

Posté par kolter (page perso, ). Modéré le 10 septembre 2006.
0
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]

> Lire la suite (72 commentaires, moyenne: 2,5).   [dépêche : 2939 caractères]

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<10-20>
| plop10 plop11 plop12 plop13 ... plop19 plop20
| % ls plop<10->
| 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
`-------------------------------------

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

oops

Posté par kolter (page perso, ) le 10/09/2006 à 10:44. (lien). É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

--
eucd.info : sauvons le droit d'auteur !!!

Zsh Rulez

Posté par Anthony Dahanne (page perso, ) le 10/09/2006 à 10:48. (lien). É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 !!!

--
Blog d'Anthony sur le logiciel libre, Java,

[+] Oui mais ...

Posté par xsnipe () le 10/09/2006 à 10:49. (lien). Évalué à -10.

... Ce genre de "news" a plus sa place dans un journal AMHA ...

--
Debian ... gentoo moi ça et vite :)

ZSH: autres fonctionnalites

Posté par malrok () le 10/09/2006 à 10:52. (lien). É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 Jérôme Poisson (page perso, ) le 10/09/2006 à 11:05. (lien). É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

la complétion dans bash ; eshell

Posté par Camille_B (Jabber id, page perso, ) le 10/09/2006 à 11:13. (lien). É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.

--
http://linuxette.blogspot.com/
http://enarkeenologos.blogspot.com/
http://www.actu-philosophia.com

Couper court au trolls

Posté par Bapt (page perso, ) le 10/09/2006 à 11:14. (lien). É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 √λιi () le 10/09/2006 à 11:19. (lien). É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.

De l'utilisation de Zsh dans les scripts systèmes...

Posté par N-Mi () le 10/09/2006 à 11:25. (lien). É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

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

Posté par acatout () le 10/09/2006 à 12:13. (lien). É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 Schopfer Jean-Claude (page perso, ) le 10/09/2006 à 13:05. (lien). É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 oops (page perso, ) le 10/09/2006 à 13:30. (lien). Évalué à 5.

hum.

Non zsh est plutôt lent et lourd, mais il fait beaucoup de choses.

chez moi ca bug

Posté par Uld (page perso, ) le 10/09/2006 à 14:38. (lien). É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...

--
Ubuntu is an ancient african word meaning : "I can't configure Debian".

et à propos

Posté par flashball () le 10/09/2006 à 14:45. (lien). Évalué à 1.

la licence ? du BSD ?

[+] ca sert a rien

Posté par Nicolas () le 10/09/2006 à 15:59. (lien). Évalué à -3.

a l'heure de monad comment pouvez vous faire la pub d'un shell qui plus est non objet </mode troll>

Défaut: unicode

Posté par RB () le 10/09/2006 à 21:50. (lien). É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.

Prompt Zsh

Posté par eddine () le 11/09/2006 à 12:35. (lien). É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.

scripts d'init en ZSH

Posté par tarreau willy (page perso, ) le 13/09/2006 à 18:38. (lien). É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

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.259s (dont 0.038 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !