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.
Forum Programmation.shell Alternatives aux shells
13
fév.
2008
# Edition de message ?
Posté par Kerro . Évalué à 3.
[^] # Re: Edition de message ?
Posté par djibb (site web personnel) . Évalué à 3.
sinon : python c'est bien.
[^] # Re: Edition de message ?
Posté par Tonton Benoit . Évalué à 2.
Pour le choix du langage perso je fait ça en fonction de l'objectif du script, ou de l'envie du moment, je ne donnerai pas ma préférence, car se serait un troll et de toutes façon elle changera peut-être demain, en ce moment je suis plutôt perl.
# Langage de script
Posté par castorpilot . Évalué à 4.
Pour ce qui est des autres shells, il me semble que zsh a la pretention de permettre de faire un peu plus de chose, de proposer plus de fonctionnalités pour les scripts, mais personnellement, je ne depasserais pas une vingtaines de lignes.
Il y a aussi BashDiff, qui rajoute des trucs sur bash, mais, euh, ça me fait peur :)
Ensuite, ben il vaut mieux se tourner vers un langage de script, comme ceux que tu mentionnes : Perl, Python, Ruby sont les plus utilisé.
Il y a aussi PHP (mais je pense que c'est surtout utilisé pour le web), Lua, TCL, ... (Il doit y en avoir des centaines !)
Pour ce qui est du C, des compilo rapides comme tcc permettent de l'utiliser comme langage de script, j'ai meme vu des "interpreteurs" de C qui proposaient une sorte de C amélioré comme langage de script. Mais franchement, ça ne me semble pas pratique, vu qu'en general, il faut pas mal de ligne de C pour avoir l'equivalent fonctionnel d'une ligne de script.
Personnellement, apres avoir utilisé/essayé plusieurs langages, j'utilise plutot Ruby. C'est evidemment une affaire de gout, et les autres langages sont tout aussi valables.
Donc en gros, pour quelques lignes, voire pour faire un one-liner direct au prompt, c'est bash, mais des que ça devient "compliqué", je le fais en Ruby. Le bonus, c'est qu'avec ces langages, on a directement acces à des librairies reseau, XML, graphiques, ....
[^] # Re: Langage de script
Posté par Nerdiland de Fesseps . Évalué à 2.
[^] # Re: Langage de script
Posté par totof2000 . Évalué à 1.
t pas autorisé à installer ces outils ...
[^] # Re: Langage de script
Posté par seginus . Évalué à 2.
En tout cas, pas mal d'outil sont programmer python ce qui fait qu'il est très souvent présent de base.
À l'heure actuelle, c'est peut-être encore vrai pour Ruby.
[^] # Re: Langage de script
Posté par totof2000 . Évalué à 1.
J'avais surtout à l'idée les Unix propriétaires qui eux ne proposent pas python, mais proposent Perl pour la plupart.
# Smalltalk !!!
Posté par blobmaster . Évalué à 2.
#!/usr/local/bin/gst -f
(1 to: 10000) do:[:it | it printOn: stdout].
!
Comme ça tes scripts pourront profiter d'un *VRAI* langage objet.
# arf...
Posté par abofrp31 . Évalué à 1.
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...
Posté par gaaaaaAab . Évalué à 2.
C'est comme écrire un pilote de périphérique en java, on peut ... mais bon ... ;)
Et le troll rebonda.
[^] # Re: arf...
Posté par totof2000 . Évalué à 1.
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...
Posté par gaaaaaAab . Évalué à 1.
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
Posté par Kerro . Évalué à 1.
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...
Posté par totof2000 . Évalué à 1.
Pas toujours. Je posterai un exemple si j'en ai dans la journée.
[^] # Re: arf...
Posté par gaaaaaAab . Évalué à 1.
mais ton exemple est quand même le bienvenu si tu as le temps de remettre la main dessus !
[^] # Conçu pour ?
Posté par Kerro . Évalué à 2.
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 ?
Posté par Mildred (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.