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] 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
| plop10 plop11 plop12 plop13 ... plop19 plop20
| % ls plop
| 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
`-------------------------------------
Aller plus loin
- [1] Csh Programming Considered Harmful (67 clics)
- [2] Pouquoi zsh c'est génial et tous les scripts systèmes devraient l'utiliser (387 clics)
- [3] Documentation de Zsh (182 clics)
- [4] Wiki francophone dédié aux applications en mode texte (297 clics)
- [5] Liste de diffusion francophone sur les shells (108 clics)
- [6] ZshWiki (149 clics)
# oops
Posté par kolter (site web personnel, Mastodon) . Évalué à 7.
# Zsh Rulez
Posté par Anthony Dahanne . Évalué à 5.
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 !!!
[^] # Re: Zsh Rulez
Posté par Yusei (Mastodon) . Évalué à 4.
Il paraît que celle de zsh est meilleure, donc si quelqu'un ayant expérimenté les deux pouvait préciser...
[^] # Re: Zsh Rulez
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 3.
Avant il y avait encore ce genre d'erreur ;-) sous bash :
* si tu tapais 'cd ' et puis tab, bash te proposait des fichiers aussi !!! Pas zsh ;-) il ne te proposait que des répertoires.
* si tu tapais 'gunzip ' bash te proposait aussi des fichiers non en .gz Pas zsh
* etc.
Maintenant, du moins avec la configuration sous Ubuntu 6.06, je ne vois plus de différence. Mais je peux te dire que je la voyais encore dans la version précédente, la 5.10...
Jean-Christophe
[^] # Re: Zsh Rulez
Posté par yoho (site web personnel) . Évalué à 5.
L'autocomplétion "intelligente" existe sur bash depuis très longtemps. Tu peux aussi autocompléter les options de programmes : par exemple, "tar[tab]" m'affiche "A c d r t u x". Le fichier qui configure cela (au moins sur ma distro) est /etc/bash_completion et tu peux rajouter tes propres completions dans /etc/bash_completion.d
[^] # Re: Zsh Rulez
Posté par Camille Vacher . Évalué à 2.
Sinon, le problème que j'avais avec zsh (il y a un an, j'ai pas réessayé depuis), c'est qu'une fois qu'il était lancé, zsh ne faisait pas la complétion pour les applications nouvellement installées. C'est possible à activer ? Ca provoque une perte de performance ?
[^] # Re: Zsh Rulez
Posté par Amand Tihon (site web personnel) . Évalué à 3.
'rehash' (man zshbuiltins) est ton ami :)
[^] # Re: Zsh Rulez
Posté par un_brice (site web personnel) . Évalué à 2.
export CDPATH='.:~:/usr:/opt:/usr/local:/usr/src:/'
shopt -s cdspell
Ensuite si tu est dans / et que tu fait cd linux, il va te mettre dans /usr/src/linux.
Même chose si tu est dans "/usr/src" et que tu tappe "cd ljnux".
Sinon les truc comme peuvent se faire avec ls plop{10..20} (en zsh aussi d'ailleurs)
Enfin, faudrais demander à un gourou du bash pour plus de précision.
Par ailleur y a l'inverse des choses dont je ne suis pas sûr qu'elles soient possibles en zsh. Notement l'utilisation de /dev/tcp/ (apparement ils ont genre de netcat à la place); ou les multiples raccourcis emacsiens.
Ceci dit je doit reconaître que la syntaxe pour les redirections m'a l'air bien plus propre, et que j'envisagerais sérieusement de remplacer bash (j'étais resté sur une idée de zsh comme d'un vieux truc pas maintenu, il se révèle plus intéressant que ça).
[^] # Re: Zsh Rulez
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
* tcsh: pratique, mais incomplet. Dans 99% des cas, on redirige stdout, ou bien les deux, et là "toto.sh >& /dev/null" est hyper pratique
* (ba)sh: on peut tout faire (y compris ne rediriger que stderr), mais le 2>&1 > /dev/null est vraiment lourd.
et en zsh, y'a les deux syntaxes ;-).
# Oui mais ...
Posté par xsnipe . Évalué à -10.
[^] # Re: Oui mais ...
Posté par xsnipe . Évalué à -8.
[^] # Re: Oui mais ...
Posté par Amand Tihon (site web personnel) . Évalué à 10.
Si les liens tout en haut de la page sont appelés « Dépêches » et « Proposer une dépêche », le lien sur lequel je clique est intitulé « Lire l'article ».
Il serait bien dommage que la page principale soit réduite à l'état d'un téléscripteur, parfois à retardement.
Cet article a très certainement fait découvrir Zsh à certains lecteurs. D'autres, comme moi, qui le connaissaient ou l'utilisaient déjà ont pu y trouver des astuces. Certains commentaires ont probablement même servi à améliorer la configuration de Bash (!) chez quelques personnes.
Je serais heureux que de temps à autres, on retrouve un article de ce type, sur un logiciel qui mérite d'être mieux connu.
Je pense (et à voir ta note, je ne suis pas le seul ici, même si personne n'a daigné te répondre avant moi) que cette catégorie d'article « découverte » mérite largement une place en première page.
[^] # Re: Oui mais ...
Posté par Mildred (site web personnel) . Évalué à 3.
Des news de ce genre, j'en voudrais plus souvent, cela m'a fait découvrir Zsh que j'utilise maintenant ... très agréable. Surtout niveau completion qui se fait en dessous de la ligne de commande et disparaît après (ca ne fait pas scroller le terminal et on garde de vue les commandes d'avant.
Et aussi niveau prompt, j'aprécie RPS1, le prompt à droite.
Dans PS1, j'ai les infos de d'habitude, username, hostname et dossier courant que je limite a deux niveaux (limite la tailel du prompt dans les niveaux profonds.
Dans RPS1, le dirname complet dans une couleur pau contrastée. Et disparaît automatiquement lorsque le curseur arrive dessus.
En plus, la couleur change selon le succès de la commande d'avant, super pratique et merci a la personne qui a donné l'astuce sur cette page.
prompt(){
autoload colors
colors
reset="$terminfo[sgr0]"
bold="$terminfo[bold]"
color_isok="%(?.%{$bold$fg[green]%}.%{$bold$fg[red]%})"
# %(!.#.$) to have '$' or '#' sign like bash / %# to have either '%' or '#'
export PS1="$color_isok%n@%M%{$reset%}:%{$bold$fg[blue]%}%2~%{$reset%}%(!.#.$) "
export RPS1="%{$fg[yellow]%}%~%{$terminfo[sgr0]%}"
}
[^] # Re: Oui mais ...
Posté par ptitmain . Évalué à 1.
Par contre, la ligne définissant PS1 ne marchait pas telle quelle. Je l'ai modifiée ainsi:
export PS1="$color_isok%n@%M%{$reset%}:%{$bold$fg[blue]%}%2~%{$reset%}> "
Sinon ca me faisait une erreur...
# ZSH: autres fonctionnalites
Posté par malrok . Évalué à 4.
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.
[^] # Re: ZSH: autres fonctionnalites
Posté par Jean-Philippe (site web personnel) . Évalué à 2.
Il y a aussi des alias sympa comme
alias -g '...'='../..'
pour faire un "cd ..."
[^] # Re: ZSH: autres fonctionnalites
Posté par Hugues Hiegel (site web personnel) . Évalué à 1.
$ setopt autocd
$ ...
même plus besoin de taper "cd " ;-)
# zsh-lovers
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
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
[^] # Re: zsh-lovers
Posté par tripa . Évalué à 8.
Et après y'en a encore pour dire que perl c'est illisible... :-)
[^] # Re: zsh-lovers
Posté par charlax (site web personnel) . Évalué à 2.
Avant avec bash il fallait faire très attention avec les "*" ; maintenant avec zsh il va falloir faire encore plus attention...
[^] # Re: zsh-lovers
Posté par Amand Tihon (site web personnel) . Évalué à 2.
C'est très pratique quand on veut vérifier que ce qu'il a trouvé correspond bien à ce qu'on pensait :)
[^] # Re: zsh-lovers
Posté par Burps . Évalué à 3.
Ca avait bougé dans la ML !
# la complétion dans bash ; eshell
Posté par Camille_B . Évalué à 3.
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.
[^] # Re: la complétion dans bash ; eshell
Posté par Aurélien Croc (site web personnel) . Évalué à 4.
urpmi xxx<tab> liste les paquetages commençant par xxx
mplayer -<tab> liste les options de mplayer
ssh <tab> liste des noms d'utilisateur
ssh utilisateur@<tab> liste les adresses des machines déjà contactées
make <tab> liste les cibles possibles
Le complètement est aussi devenu un peu plus intelligent dans le sens où
cd xxx<tab> ne listera que les répertoires
mplayer -sub <tab> ne listera que les fichiers .sub et .srt
rpm -ivh <tab> ne listera que les fichiers .rpm
etc.
Bien entendu ça n'est peut être pas aussi important que tout ce qu'est capable de faire zsh ; mais j'ai souvent entendu parler de zsh pour son complètement et les choses semblent bouger sur bash pour implémenter cela.
[^] # Re: la complétion dans bash ; eshell
Posté par Mildred (site web personnel) . Évalué à 3.
Je ne sais plus pourquoi j'avais ce problème, mais par exemple, si tu veux dézipper un fichier ODT, tu ne peux pas (mauvaise exstension) ...
file file.odt
file.odt: Zip archive data, at least v2.0 to extract
[^] # Re: la complétion dans bash ; eshell
Posté par Amand Tihon (site web personnel) . Évalué à 7.
Alors je viens de la tester sous bash, et je suis déçu. Effectivement, elle ne complète que sur ce qui lui convient.
Zsh a la décence de compléter sur autre chose quand ça ne tombe pas juste.
Sous bash :
allergy@hali:/tmp/ic$ ls
document.odt fichier.zip
allergy@hali:/tmp/ic$ unzip d[TAB]... Et il ne complète pas.
Sous zsh, il constate qu'aucun fichier d*.zip n'est présent, alors il complète avec ce qu'il trouve, c'est à dire document.odt.
Autre chose que j'aime : il complète également dans la partie "chemin" d'un hôte distant lors d'un scp. Très pratique, à condition d'utiliser les clés pour ssh :)
Enfin, il permet de compléter en une seule fois une commande du type :
tail -f /v/l/a/er[TAB] en tail -f /var/log/apache2/error.log.
Il s'arrête éventuellement à la première ambiguïté et il y met le curseur :
allergy@hali:~$ ls /tmp/ic/d*/*
/tmp/ic/dir1/fichier /tmp/ic/dir2/fichier (d1 ou d2)
allergy@hali:~$ cat /t/i/d/f[TAB] devient :
allergy@hali:~$ cat /tmp/ic/dir / f (J'ai souligné la position du curseur).
Il ne reste plus qu'à entrer "1" ou "2", et refaire [TAB].
[^] # Re: la complétion dans bash ; eshell
Posté par tomachaka . Évalué à 6.
Ce n'est pas le comportement par défaut apparemment, mais on peut configurer la completion de bash de la même façon
complete -o comp-option
comp-option may be one of:
bashdefault: Perform the rest of the default bash completions if the compspec generates no matches.
dirnames: Perform directory name completion if the compspec generates no matches.
> il complète également dans la partie "chemin" d'un hôte distant lors d'un scp
Dans bash aussi :)
[^] # Re: la complétion dans bash ; eshell
Posté par Krunch (site web personnel) . Évalué à 1.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: la complétion dans bash ; eshell
Posté par chtitux (site web personnel) . Évalué à 5.
Display all 301 possibilities? (y or n)
chtitux@localhost ~/videos $ ls ../
chtitux/ user1/ user2/ jamendo/
Surprenant ?! :)
Réponse :
chtitux@localhost ~ $ ls -l videos
lrwxrwxrwx 1 chtitux users 14 mai 24 16:35 videos -> /home/jamendo/
La complétion ne suit pas les liens, mais ls si :
~/videos $ ls ../ == /home/jamendo $ ls ../
(bug ou feature, on m'a répondu feature sur #bash ...)
# Couper court au trolls
Posté par Bapt (site web personnel) . Évalué à 3.
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 Anonyme . Évalué à 5.
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.
[^] # Re: Il fut un temps ...
Posté par jerome (site web personnel) . Évalué à 2.
[^] # Re: Il fut un temps ...
Posté par Anonyme . Évalué à 2.
[^] # Re: Il fut un temps ...
Posté par Anonyme . Évalué à 2.
Mais effectivement, on peut utiliser cette commande pour sauvegarder l'historique a chaque validation de commande, et le charger a chaque fin de commande (je crois que bash permet ca). Mais j'ai peur pour les performances :)
Mais j'ai regardé la doc de zsh, ce n'est pas une option intégrée dans zsh, étonnant puisque je l'avais compilé moi même.
[^] # Re: Il fut un temps ...
Posté par pikapika . Évalué à 1.
http://roo.no-ip.org/fish/
# De l'utilisation de Zsh dans les scripts systèmes...
Posté par N-Mi . Évalué à 10.
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
[^] # Re: De l'utilisation de Zsh dans les scripts systèmes...
Posté par neologix . Évalué à 2.
Bon, cette remarque m'étonnait, alors j'ai fait un test très con, mais très parlant.
En mode "login automatique", j'ai mesuré le temps entre le moment ou je lance les OS depuis grub, et le moment où le pc est utilisable, c'est-à-dire quand il n'y a plus d'accès disque.
Voilà les résultats:
-Debian Etch + KDE 3.5: 43s
-Windows XP SP2 : 1m45s
Et c'est valable sur mes autres pc.
Quand je suis passé à Linux, c'est vrai que le démarrage n'était pas super-rapide.
Mais ça confirme ce que je pensais, ça s'est vachement amélioré, notamment avec udev/hotplug (et le noyau 2.6.15).
Mes linux démarrent bien plus rapidement.
Précision: mon XP est bien customisé (pas de msn qui se lance au démarrage, pas de winamp, services inutiles désactivés, etc).
mon linux reconnaît bien mon wifi, ma webcam (Logitech QuickCam Communicate STX, très bien pour le manchot, même le micro marche), donc ce n'est pas biaisé.
Après, c'est vrai que j'utilise une Debian, et ça doit être plus rapide qu'une distribution user-friendly, mais je ne connais que Debian.
Voilà voilà, je vous invite à comparer, parce que ce que je peux lire m'étonne.
[^] # Re: De l'utilisation de Zsh dans les scripts systèmes...
Posté par snt . Évalué à 8.
>les OS depuis grub, et le moment où le pc est utilisable, c'est-à-dire quand il n'y a
> plus d'accès disque.
J'espere pour toi que ton PC est utilisable aussi quand il y'a des acces disque !
Evidemment ta methode de chronometrage est largement à l'avantage de linux : windows est pensé pour du desktop : il donne la main à l'utilisateur le plus rapidement possible et continue à démarrer des services en background. Apres ça, il fait son petit processus de reorg des fichiers sur disque pour accelerer le prochain boot. Mais il est utilisable bien avant ça. Enfin au moins chez moi et au boulot.
Puisqu'il s'agit de donner des chiffres, je te donne les miens :
- kde 3.5 avec boot parallele et un genre de readahead en autologin : 40 secs avant d'etre capable de lancer un konqueror pour faire office d'explorateur de fichier
- windows xp sp2 sur la meme machine : 10 secs de moins pour lancer explorer.exe. Et c'est en comptant le temps que je tape mon login !
Bien entendu je precise pas qu'il a fallu que je lutte à mort pour arriver à ces resultats avec linux ( generation de mes listes de fichiers perso pour le read ahead. Désactivation de certains services pour les relancer plus tard. Chronometrages en tout genre pour garder la meilleure soluce à chaque fois ). Sous windows, j'ai rien eu à faire.
Une des différences c'est que windows ne boote pas avec des scripts. Les scripts c'est bien pour débugguer, c'est pratique pour diffuser des patchs et tout, mais quand il s'agit d'aller traquer la seconde, c'est moins chouette.
[^] # Re: De l'utilisation de Zsh dans les scripts systèmes...
Posté par neologix . Évalué à 3.
Oui, mais ça rame à mort, donc cela ne compte pas.
Pas chez moi. Windows n'est pas utilisable avant ce temps, pendant qu'il lance tous ses services, etc. Ce n'est pas le fait de voir la prairie qui permet de bosser. Au contraire, c'est exaspérant d'avoir l'impression que ton pc est prêt, alors qu'il ne l'est pas du tout.
Mon kde est utilisable avant même que windows n'en soit au stade du login!
Cela m'étonne énormément. Quelle distribution utilises-tu? Tu utilises ntpdate, dhcp, tu recompiles ton noyau à chaque démarrage ;-) ?
[^] # Re: De l'utilisation de Zsh dans les scripts systèmes...
Posté par moramarth . Évalué à 2.
Mac OS : 37"
Ubuntu : 1'36"
D'un côté, Edgy est encore en développement et on peut estimer que les choses vont s'améliorer, de l'autre, edgy inclut déjà certaines optimisations de vitesse de boot…
Il est vrai aussi, que Panther est spécifiquement conçu pour ces machines quasiment : il n'a même pas de support 64bits, et encore moins d'autre architectures, sans parler de milliers de modèles de PC différents…
Reste qu'en tant qu'utilisateur, je sens bien la différence de vitesse de boot.
La vitesse d'extinction (que tout le monde oublie alors qu'elle compte bien dans le redémmarage, opération que j'effectue régulièrement) est aussi à l'avantage de Panther, quoiqu'Ubuntu ait fait d'énorme progrès en la matière avec Edgy…
[^] # Re: De l'utilisation de Zsh dans les scripts systèmes...
Posté par Pinaraf . Évalué à 3.
Dans le futur ça changera, mais ça sera pour Edgy + 1.
[^] # Re: De l'utilisation de Zsh dans les scripts systèmes...
Posté par Jean-Philippe (site web personnel) . Évalué à 2.
Bon c'est bien au pifomètre je te le concède, mais je ferai surement un benchmark pour voir.
Rien à voir tout de même avec initng ou meme pinit par exemple
[^] # Re: De l'utilisation de Zsh dans les scripts systèmes...
Posté par Nicolas Deveaud . Évalué à 1.
Je suis tout de même très sceptique sur la "customisation" de ton XP.
J'ai réinstallé XP pro sur mon pc la semaine dernière, en désactivant les trucs inutiles activés de base (services inutiles, msn, etc...).
Mon PC met moins de 40 secondes à booter sous XP, depuis le moment où je presse l'interupteur, jusqu'à l'invite de login, en passant par le grub (et la sélection d'OS que je fais manuellement).
Une fois à l'invite de login, le tout est quasiment totalement chargé, le temps que j'entre mon login, que je valide et que le bureau s'affiche, tout est chargé, près à l'usage.
Donc XP en lui même doit mettre pas plus de 40 secondes à se charger totalement.
Et ma machine à 5 ans, donc c'est pas non plus une bete de coursse.
Linux à de gros avantages sur windows.... mais au niveau démarage, pour le moment je donne plutot windows gagnant.
[^] # Re: De l'utilisation de Zsh dans les scripts systèmes...
Posté par gpe . Évalué à 1.
Enfin, pour apporter ma petite contribution, sur mon portable (P4M 1,6GHz, 512Mo, HD 80Go/5400tr/min), je dirais que XP arrive plus vite sur l'écran de login que Linux/Debian testing, mais que Gnome est plus vite opérationnel que le bureau XP, qui apparaît certe très vite mais reste inutilisable très longtemps!
[^] # Re: De l'utilisation de Zsh dans les scripts systèmes...
Posté par Guillaume D. . Évalué à 3.
je redemarre XP 1 fois par jour minimum,
alors que ma gentoo ....
$ uptime
13:09:37 up 17 days, 14:55, 4 users, load average: 0.71, 0.18, 0.08
noyau (2.6.17-gentoo-r4) oblige ....
donc demarrage gentoo + KDE plus d'une minute tous les mois
et XP 40 secondes tous les jours ....
choisissez votre camps !
[^] # Re: De l'utilisation de Zsh dans les scripts systèmes...
Posté par Gniarf . Évalué à 1.
(ah, et comparer des temps de boot, c'est assez idiot de partir du moment où on pousse le bouton on/off, on conseille souvent de compter à partir du chargement du bootloader, soit après le POST (Power-on self-test))
[^] # Re: De l'utilisation de Zsh dans les scripts systèmes...
Posté par neologix . Évalué à 2.
Ah.
On en reparlera quand le système de fichier sera fragmenté, que la base de registre sera plus bordélique que la chambre des mes copiaules américains, etc. As-tu un antivirus, ton XP est-il à jour (bah ouais, le SP2 il te plombe bien la machine)? Tu peux répondre que ce n'est pas indispensable, mais là je te dirai que cela fait parti de WIndows, étant donné qu'ils conseillent fortement d'avoir un antivirus (y'a qu'à voir la tronche que fait le centre de sécurité sinon), et que les machines sans service pack 2 ne seront bientôt plus supportées. Démarrer un windows XP à jour sur un pc vieux de 5 ans en 40 secondes est totalement impossible.
[^] # Re: De l'utilisation de Zsh dans les scripts systèmes...
Posté par lezardbreton . Évalué à 2.
[^] # Re: De l'utilisation de Zsh dans les scripts systèmes...
Posté par kolter (site web personnel, Mastodon) . Évalué à 3.
si on en croit la personne qui a travaillé sur le projet SoC pour l'amélioration de la vitesse de boot de debian ( http://bootdebian.blogspot.com/ ) , le gain en parallèlisant les scripts est très faible (environ 4s ).
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.
Ce qui prend surtout du temps (AMA) c'est tout simplement l'exécution du service en lui même, le service qui peut avoir à lire des fichiers de configurations, checker des données, etc ...
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
c'est pas vraiment un argument, zsh doit peser à peine 500 ko, sachant que dans les paquets de base d'une majeure partie, tu as perl qui por une installation minimal te prendra beaucoup plus de place.
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
c'est indéniable, ceci dit, quand on voit upstart qui sera un espèce de démon fourre tout (init, cron, udev, inetd?) où on rompt avec la tradition "faire une chose, mais la faire correctement", on peut très bien envisagé de faire une rupture complète et essayer de faire un des scripts d'init en zsh avec une bibliothèque de fonction zsh pour remplacer les outils tels que sed, cut, grep, awk. C'est une idée mais ça peut être intéressant si les résultats sont là.
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
si on raisonne comme ça, on serait toujours à faire du basic, après si les dev ne veulent pas évoluer, apprendre de nouvelles choses, je ne donne pas cher de leur avenir dans l'informatique dans 10 ans au train où ça évolue. Après, zsh à une doc et comme signalé dans l'article il y'a des wiki, des listes de diffusions, des canaux irc, etc ...
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 performancespas insurmontable à mon avis...
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.
je suis pas d'accord, je suis utilisateur des langages de scripts (non shell) que tu sites et il est à mon avis souvent bien plus rapide d'utiliser un script shell pour certains tâches.
M.
[^] # Re: De l'utilisation de Zsh dans les scripts systèmes...
Posté par Pinaraf . Évalué à 3.
# Ma fonctionnalité préférée : l'invite sensible au code de retour
Posté par acatout . Évalué à 2.
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.
[^] # Re: Ma fonctionnalité préférée : l'invite sensible au code de retour
Posté par ribwund . Évalué à 3.
http://gentoo-wiki.com/TIP_Exit_Status_in_prompt
# Le chemin du changement
Posté par dactar (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 5.
Non zsh est plutôt lent et lourd, mais il fait beaucoup de choses.
# chez moi ca bug
Posté par Uld (site web personnel) . Évalué à 2.
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...
[^] # Re: chez moi ca bug
Posté par Smarter . Évalué à 1.
[^] # Re: chez moi ca bug
Posté par oops (site web personnel) . Évalué à 6.
Alors que tu serais un vrai emacsien tu ferais Ctrl-a ;-)
[^] # Re: chez moi ca bug
Posté par xof . Évalué à 2.
As-tu essayé :
C-a (Déplacement au debut de la ligne courante)
C-e (Déplacement en fin de ligne courante)
Feature : Ça marche aussi sous emacs :)
[^] # Re: chez moi ca bug
Posté par Camille_B . Évalué à 1.
Normal c'est les raccourcis d'Emacs ;)
Il est également possible de passer en mode vi (du moins sous bash) :
set -o vi
[^] # Re: chez moi ca bug
Posté par Arnaud Leroy . Évalué à 1.
Il suffit de rajouter au début de son .zshrc :
autoload zkbd
zkbd
Ensuite on lance son terminal où zsh va y poser plusieurs questions et demander d'appuyer sur quelques touches (F1 à F12, suppr, home, end, haut, bas, etc ...)
Ensuite il suffira de lire ce qui est dit à la fin pour finir la configuration.
# et à propos
Posté par flashball . Évalué à 1.
[^] # Re: et à propos
Posté par Hank Lords . Évalué à 1.
# Commentaire supprimé
Posté par Anonyme . Évalué à -3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ca sert a rien
Posté par Camille_B . Évalué à 1.
Scheme ;)
Et oublie Monad ... :D
# Défaut: unicode
Posté par RB . Évalué à 2.
[^] # Re: Défaut: unicode
Posté par Gniarf . Évalué à 1.
[^] # Re: Défaut: unicode
Posté par ercete . Évalué à 1.
mais depuis mon passage en utf8 c'était devenu un calvert...
donc je suis retombé à Bash.
Content d'apprendre qu'en devel l'utf8 avance mais depuis le temps je trouve l'évolution un peu lente (c'est pas un reproche, pas taper !)
enfin je me souviens souvent avoir lu des réprimandes avec des .zshrc mal configurés qui empêchent root et les user de se logguer...
et bien je tiens à dire que c'est largement faisable avec bash aussi, j'en ai pour preuve ma propre experience :p
# Prompt Zsh
Posté par FueL . Évalué à 1.
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.
[^] # Re: Prompt Zsh
Posté par Amand Tihon (site web personnel) . Évalué à 1.
Exemple chez moi, où j'affiche sur la ligne au dessus du prompt, le code de retour de la commande précédente s'il est différent de 0.
_exitcode="%(?::${C_BRED}[ %? ]${C_NO}
)"
Oui, le retour à la ligne est simplement balancé dedans :)
[^] # Re: Prompt Zsh
Posté par FueL . Évalué à 1.
[^] # Re: Prompt Zsh
Posté par Amand Tihon (site web personnel) . Évalué à 2.
allergy@hali:~$ ENDL="
dquote> "
allergy@hali:~$ echo "Une et${ENDL}Deux lignes"
Une et
Deux lignes
# scripts d'init en ZSH
Posté par tarreau willy (site web personnel) . Évalué à 3.
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
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.