Programmation.shell : Alternatives aux shells
Posté par Kerro () le 13 février 2008
0
Bonjour,
j'utilise Bash depuis des années pour tout un tas de "petits" programmes. Par exemple pour récupérer des fichiers depuis un ftp, manipuler leur contenu, et envoyer le résultat dans une base de données. Ou pour effectuer des sauvegardes et les envoyer sur un serveur distant tout en gérant l'historique etc.
Mais Bash ne me convient pas en fait. C'est très bien lorsque j'ai 10 lignes, mais à partir de 100 ou 200 c'est la foire. Trop de particularités à gérer. Obligé d'utiliser des astuces pour arriver à faire ce que je veux. Et telle astuce fonctionne uniquement dans tel cas, des choses comme ça.
Je me pose depuis pas mal de temps la question d'utiliser autre chose que Bash. J'ai regardé les autres shells. Sauf erreur de ma part, ce n'est pas mieux question "propreté". A leur décharge, les shells n'ont à mon avis pas été conçu pour programmer des choses de centaines de lignes. Juste pour scripter un peu.
Je me dis qu'en programmant en PHP ou Python, Ruby, Perl, ce serait probablement mieux. J'ai regardé quelques discutions ici à propos des langages de remplacement de Bash, j'ai trouvé des fils de discution assez anciens.
Quelqu'un a-t-il l'expérience d'utiliser un langage autre qu'un shell pour "scripter" ?
Le C, que je connais plutôt très bien, ne me semble pas adapté pour mes besoins. Bien que, bien que.
> Lire le message (18 commentaires, moyenne: 1,7).
Vous avez demandé le commentaire #904578.
Run by 
Cette page a été générée par Templeet en 0.0599s (dont 0.0054 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
arf...
salut,
A leur décharge, les shells n'ont à mon avis pas été conçu pour programmer des choses de centaines de lignes. Juste pour scripter un peu.
ca excuses moi mais ca me fait bien marrer.... a mon boulot, par exemple on est 4 pour gerer en gros 1000-1500 jobs par jours chacun est un script shell d'environ 1200 a 3000 lignes.... selon les applications qu'ils gerent...
par contre oui c'est pas si simple qu'avec un langage fait pour scripter a la tonne parcequ'il manque des choses pour se faciliter la vie ...
Quelqu'un a-t-il l'expérience d'utiliser un langage autre qu'un shell pour "scripter" ?
perl est probablement l'un des plus courrant et performants.
[^]Re: arf...
oui, personne dit qu'on ne peut pas, juste que ça n'a pas été conçu pour ça.
C'est comme écrire un pilote de périphérique en java, on peut ... mais bon ... ;)
Et le troll rebonda.
[^]Re: arf...
oui, personne dit qu'on ne peut pas, juste que ça n'a pas été conçu pour ça.
Si ...
En fait le shell a été conçu pour "faire faire".
En gros il y a quelques commandes internes, et ensuite ce sont les commandes de ton OS que tu fais exécuter par le shell.
Ce qui explique que selon la tache à réaliser, c'est soit awk qui sera le plus efficace, soit sed, soit tr, etc ....
[^]Re: arf...
Ne nous méprenons pas, je suis un grand fan du shell ! et en ligne de commande, je me fais plaisir. Si malin passe dans la coin, il confirmera peut -être ;)
Mais quand les outils shell que tu utilises pour contrôler tes applications deviennent bien gros, ça devient compliqué à maintenir.
Un des points qui me gène le plus dans le scripting shell, c'est la gestion d'erreur, que je trouve trop couteuse par rapport à d'autres langages de script .
Pour finir, en guise d'illustration, deux lignes jetables pas optimisées à lancer dans un /usr/bin qui donne chez moi :
$ wc -l `file * | grep Bourne | cut -d ':' -f 1` | grep -v total | awk '{tot = tot + $1}END{print tot " / " NR " ; " tot / NR}'
30066 / 246 ; 122.22
$ wc -l `file * | grep perl | cut -d ':' -f 1` | grep -v total | awk '{tot = tot + $1}END{print tot " / " NR " ; " tot / NR}'
85325 / 111 ; 768.694
Soit une longueur moyenne de 122 lignes pour les scripts sh et de 768 pour les script perl, alors que la syntaxe de perl est beaucoup plus compacte que celle du shell.
Je n'ai pas calculé l'écart type, mais j'ai vérifié que c'est pas un script perl de 50000 lignes qui fait monter la moyenne.
maintenant, à chacun d'en tirer les conclusions qu'il veut :)
[^]Nombre de lignes
Je n'ai pas compris si en calculant tes nombres de lignes tu voulais montrer que Bourne est plus compact, ou que Bourne est utilisé pour des choses plus simples chez toi.
Tu soulèves un point auquel j'adhère : la gestion des erreurs.
Il y en a d'autres, mais ça ne me vient pas à l'esprit facilement.
De mon point de vue, le nombre de lignes n'est pas forcément pertinent.
Par exemple pour lancer un processus séparé, en shell il suffit juste d'ajouter un '&' à la fin de la ligne. Un seul caractère, difficile de faire mieux.
Par contre pour savoir si le lancement est réussi, pas moyen de le savoir.
Et le fait qu'il suffise d'un seul caractère, ça n'engage que moi, je trouve que c'est illisible. Pour un petit script c'est parfait, vraiment. Mais au delà de 50 ou 100 lignes, il faut lire hyper précisément pour saisir des choses très importante.
[^]Re: arf...
la syntaxe de perl est beaucoup plus compacte que celle du shell.
Pas toujours. Je posterai un exemple si j'en ai dans la journée.
[^]Re: arf...
je ne doute pas qu'on puisse trouver. Je rectifie : "la syntaxe de perl est *généralement* beaucoup plus compacte que celle du shell" ;-)
mais ton exemple est quand même le bienvenu si tu as le temps de remettre la main dessus !
[^]Conçu pour ?
Je n'ai pas l'impression que les shells aient été fait pour construire des applications de centaines de lignes.
Il suffit de voir "la gueule" d'un script Bash de 200 lignes, c'est parfaitement illisible par rapport à la même chose en Python (que je suis tout juste en train de découvrir).
Un script en shell c'est juste fait pour mettre en place de menues automatisations. Pas des usines.
C'est juste ma conviction.
[^]Re: Conçu pour ?
Si tu structure bien ton script, il peut atteindre 200 lignes sans qu'il soit illisible ... mais peut être pas beaucoup plus, c'est vrai. Mais c'est vrai pour tout fichier. A un moment tu dois utiliser plusieurs fichiers ou alors tu t'y perds.
La Roue du Temps