À 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.
# De l'utilisation de Zsh dans les scripts systèmes...
Posté par N-Mi . En réponse à la dépêche À la (re)découverte de Zsh. É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