Re: zsh vs bash
Ce n'est pas un troll selon moi car c'est constructif, argumenté et appuyé par des exemples concrets.
Usuellement, on choisit ses premiers outils parce qu'on a besoin de régler un problème plutôt urgemment (et on n'a donc pas le temps d'étudier tout ce qui se existe). Alors, on prend l'outil dont on a le plus entendu parler. Et c'est rarement le meilleur outil (tiens, ça me fait penser à pourquoi les gens ont utilisé aussi massivement Windows et Office... ; et aussi à comment je percevais Linux avant de décider de l'utiliser : trop compliqué, un truc pour les experts).
Ton message n'est pas un troll mais un cadeau.
Merci !
----- Original Message -----
From: Marc Chantreux <mc@unistra.fr>
To: roger tarani <roger.tarani@free.fr>
Cc: 'Liste Debian' <debian-user-french@lists.debian.org>
Sent: Mon, 24 Dec 2018 12:25:29 +0100 (CET)
Subject: zsh vs bash
salut,
(parceque j'aime lancer un troll a quelques heures du départ en vacances)
> zsh : je suis resté à bash car situé entre le vieux sh et l'évolué
> esh et capable de faire tourner tous les scripts (bash et sh, mais pas
> zsh je crois). Mais la syntaxe de zsh serait beaucoup(?) plus riche.
j'ai été un grand fan quand je ne connaissais que les shells
historiques, j'ai même été à l'origine de la traduction francaise d'ABS
(advanced bash scripting) ... j'ai découvert zsh parceque quelqu'un
avait écrit un post je ne sais plus ou lors de la sortie d'une version
majeure de bash (v3.0 je crois). la conclusion était que l'amélioration
était significative mais que bash restait à la traine. il conseillait de
regarder zsh ... ce que j'ai fais.
depuis je ne subit bash que parceque d'autres me l'infligent (par contre
je me suis mis a utiliser mksh, le ksh de openbsd et rc) en produisant
des outils qu'il m'arrive de devoir maintenir.
le shell scripting a deux énemis à mes yeux:
* la croyance dans la portabilité POSIX
* bash ... un shell a peine superieur à mksh avec le rapport
poids/puissance le pire du monde
mes choix actuels sont
* lorsque j'ai besoin de qqchose de léger, j'utilise rc (fourni par le
paquet 9base)
ou mksh.
* lorsque j'ai besoin de confort (tant pour la puissance de zle que pour
la richesse du langage)
maintenant à chaque fois que quelqu'un vient me montrer les évolutions
de bash, c'est un peu comme quand on me parle de l'évolution de python
ou JS: je trouve ça super cool que mon interlocuteur aie enfin à
disposition des fonctionalités que j'utilise depuis 20 ans mais pourquoi
avoir attendu tout ce temps ? jette un coup d'oeil dans man zshexpn:
cette partie du manuel à elle seule justifie de switcher. (si tu fais
man zsh, tu tombes sur la liste de toutes les sections) je ne détaille
pas ici parceque ce serait vite un roman mais
* une chaine est une chaine (le word splitting n'est pas automatique),
c'est con mais ca rend l'écriture plus naturelle quand tu viens de
langages dynamiques
* il y a plein de raccourcis pratiques pour modifier des chaines ou des
tableaux
cd =perl6(:A:h:h)
est l'équivalent de
cd $( dirname $( dirname $( realpath $( which perl6 )))
= => which
:A => realpath
:h => dirname
notes que tu a evité plein de forks juste parceque la syntaxe vole à
ton secours. c'est souvent le cas
* la syntaxe "alternative" (cf. zshmisc) est pour moi suffisante
for it in *.svg; do
gzip -c9 $it
done
s'écrit en zsh
for it (*.svg) gzip -c9 $it
perso j'ai un petit alias
@='for it'
du coup au quotidien j'écris plutot
@ (*.svg) gzip -c9 $it
* les extendedglob ... permettent des choses extrêmement puissantes
(comme le fait de pouvoir rajouter ses propres filtres, le ** pour
les motifs récursifs) ... globs que tu peux stocker dans des variables
que tu vas pouvoir ensuite jouer avec le modifier ~
images='(#i)*.(png|jpe#g|svg)'
@ ( a.png a.PNG a.jpg a.jpeg ) { [[ $it == $~images ]] && echo ok }
ls -l **/$~images # recursive parceque ** (adieu find dans les cas
simples)
* le shell courant lit dans le dernier élément du pipe courant. ca a
l'air de rien comme ca parceque tu te dis que les deux lignes
suivantes se valent
hostname | read h
h=$(hostname)
sauf que pouvoir écrire
fmt='$login is member of $gid'
getent passwd mc | IFS=: read login _ uid gid _
print ${(e)fmt}
mc is member of 1000
note l'expansion modifier e (evaluation) qui te permet de créer des
templates. si tu utilises les glob expansions en plus tu peux écrire
des trucs cools du genre
fmt='%F{blue}$login%f is member of %K{red}$gid%k'
getent passwd mc | IFS=: read login _ uid gid _
print ${(%e)fmt}
et voilà de la couleur :)
> En pratique, c'est quoi les avantages et les inconvénients de zsh (par rapport à bash) ?
l'expressivité de zsh permet d'éviter des forks a répétitions à base de
bricolages qui l'ont de sens que lorsque tu les écris comme t'obligent à
en faire les shells traditionnels. zsh n'est pas seulement plus
aggréable à écrire mais aussi tellement plus aggréable à maintenir.
le seul inconvénient c'est qu'il y a beaucoup de choses écrites en/pour bash.
il m'arrive donc souvent de prendre un script et de le réécrire avec mes
conventions, me coupant ainsi d'une possible communauté upstream.
> Y a-t-il un moyen de travailler (zsh ou bash) avec une double syntaxe,
> cad la syntaxe fine pas facile à mémoriser à moins de l'utiliser tout
> le temps, et une syntaxe plus facile à mémoriser ?
les bases de bash et zsh sont les mêmes: ksh. apres tu vas avoir de
petites subtilités. je parlais par exemple du word splitting
words="they don't come easy"
for w in $words; do
echo $w
done
te donne ca sous bash
they
don't
come
easy
et ca sous zsh
they don't come easy
parcequ'en zsh, une chaine est une chaine, un tableau est un tableau, et
tu peux splitter ($=words) une chaine en mots
donc les versions zsh sont
words=(they don't come easy)
for w in $words; do
echo $w
done
ou
words="they don't come easy"
for w in $=words; do
echo $w
done
et si tu veux dépiler des trucs compliqués avec des " et des ' dedans,
regarde du coté de (z) et (Q) et rcquotes. exemple
command_with_parameters='say "another word" and "i''ll use zsh"'
@ ( ${(Q)${(z)command_with_parameters}} )
print $it
say
another word
and
i'll use zsh
notes que j'ai écris i''ll alors que j'étais dans une chaine
simplement quotée: merci rcquotes.
(z) splite la chaine en tableau avec le zsh parsing, en résulte un
tableau.
(Q) vire les quotes proprement... comme c'est appliqué au tableau
produit par ${(z)...}, ce sont tous les éléments du tableau qui vont
être traités séparément.
je pourrais continuer pendant des heures. notons aussi que zsh sais
travailler avec des références symboliques de variables et evite bien
des bricolages a coup de eval
> Existe-t-il une sorte
> d'éditeur qui permette d'avoir la commande en zsh ou en RE, et sa
> traduction en quelques exemples faciles à mémoriser ?
le meilleur éditeur est la CLI elle-même: si tu as configuré la
completio (compinit), tu as plein d'informations en plus des
propositions elle-même.
> J'espère que je suis clair.
je crois comprendre et je te rejoinds: ne pas apprendre te force à
réinventer pauvrement (et c'est une quote d'un unixien celebre ... Denis
Ritchie je crois).
a+
marc
Reply to: