Yopi Marc Chantreux a écrit :
Philippe Jacquot a écrit :
Na, c 'est juste que, bon, convertir un .csh en .sh c'est pas trop dur, mais un .zsh plein des bêtes dont tu causes, ça doit être un peu plus hardu.
faux : tous ces zshismes peuvent aisément etre remplacés si besoin par des commandes externes ( find + wc dans notre cas).
Bah oui comme pour Bash quoi.
l'avantage de zsh, c'est justement que l'interpreteur lui-meme est assez riche pour eviter de faire appel a ces commandes. les gains :
- portabilité : - je ne suis pas obligé de verifier les parametres passés a mes commandes externes ( gnu vs BSD vs Sun vs ... ) - l'implementation de zsh est identique sur tous les systemes, on a parfois des surprises avec sh. - rapidité - d'excution : pas de pipe, pas de forks - d'ecriture : je prefere ecrire - rm **/*py plutot que rm $( find -name '*py' ) - file =ls plutot que file $(which ls) - ...
maintenant, je ne vois pas l'interet que je pourrais avoir a reecrire en un autre shell ce que j'ai écris en zsh. Tannnenbaum dirait que ce serait reprendre en basic qqchose qui a ete écrit en C et qui fonctionne.
Mais y'avait aucun reproche dans mes propos. :-)
je n'en doute pas. de mon coté, zsh m'a vraiment permis d'etre plus productif, le simple fait de pouvoir ecrire des choses comme : for f ( *txt ) gzip $f for f ( *txt ) { gzip $f ; echo $f zipped } me ravi.
tu comprendras donc mon proselytisme.
Tu prêches un convaincu :-) Je disais juste que l'aspect didactique de formules telles que **/* n'est pas évident de prime abord. Mais tout autant qu'un ${var%%.ext}.
cordialement mc
PS: tu me repond personnellement par accident ou veux tu que nous continuions cette discution en privée ?
Na.. Je sais bien que c'est mâââl, mais je suis habitué à faire juste "Répondre". A bas le Dogme. :-) pj -- Sparx Inc. 34 rue du Sentier 75002 Paris Tel. +33 (0) 1 44 34 29 21 Std +33 (0) 1 44 34 29 29 Fax +33 (0) 1 55 73 17 07 http://www.sparx.com