Salutations,
J'aimerais avoir votre avis concernant ces langages/outils dans le cadre de l'administration système.
Il fut un temps où le shell était l'unique point central dans la gestion quotidienne d'un système Linux. Mais ses limites ont vite été mise en surface, et le perl est né, extension d'un awk plus puissant, et naissance d'un langage de programmation.
Pendant l'ascension du perl, un autre s'est faufilé, et s'est fait appeler Python.
Il n'en reste pas moins que le choix de l'administrateur est perturbé : bien qu'il considère le perl comme pouvant remplacer aisément le shell, il hésite également à s'aventurer vers le python.
Quel est donc selon vous le langage le plus apte pour une administration système ? Perl, Python ou juste du shell ?
merci.
Forum Linux.général [Programmation] Shell / Perl / Python
28
avr.
2009
# melting pot...
Posté par aurel (site web personnel, Mastodon) . Évalué à 5.
Au final, pour les usagers que j'ai autour de moi, il n'y a guère que python qui ne se mélange que rarement aux deux précédents. "Pour de l'admin système, c'est un peu excessif de sortir un "vrai" langage (patapé)".
--> []
[^] # Re: melting pot...
Posté par mekare . Évalué à 1.
Tout dépend de tes besoins. Toutefois apprendre un nouveau langage permet d'ouvrir d'autres horizons et de s'adapter à différentes plateformes et formats de données.
# perl ?
Posté par Dabowl_92 . Évalué à 2.
En effet, tout du moins sous Aix, l'interpréteur python n'est pas installé par défaut, mais cela reste evidemment possible de l'ajouter par la suite (dans les fileset GNU fournis par ibm je suppose)
Sous solaris, je n'en sais rien mais ça m'étonnerait.
Après d'un point de vue syntaxe, le perl reste quand même plus proche du bash, donc c'est moins déroutant pour l'admin.
Pour moi, perl remplace avantageusement le shell pour tout traitement un tant soit peu complexe (on evite de multiplier le nb de process cut, grep, etc... que l'on rencontrerait avec du bash/ksh).
Maintenant, je ne saisis toujours pas l'intérêt du python, je ne déteste pas l'approche objet, mais pour de l'admin ça me parait démesuré ; après c'est vrai qu'on est pas obligé de faire de l'objet avec python mais bon on se retrouve avec une syntaxe bien mois familière, donc pour quel bénéfice finalement ?
J'espère que les pythonneux vont arriver à me convaincre à m'investir dans ce langage !
[^] # Re: perl ?
Posté par totof2000 . Évalué à 2.
Je ne peux que te conseiller de t'investir un peu dans ce langage, ne serait-ce que par curiosité intellectuelle, et pour savoir si tu passes à côté de quelque chose ou non.
Personnellement je ne suis pas pythonneux, mais je m'y suis mis pour le comprendre et voir ses qualités/défauts.
J'étais perleux avant, et j'étais capable d'écrire des programmes qui poussaient assez loin les possibilités du langage en jouant sur le style de programmation. Cependant, celà rendait mes programmes assez illisibles pour les autres .... et pour moi lordque je devais les retoucher un ou deux ans après. De plus la gestion de la programmation objet est assez rustique et fastidieuse, même si elle existe, et ça j'aime pas trop ....
Python c'est un peu l'autre extrême: assez rigide et une seule façon de faire. C'est pratique pour la relecture mais ça peut être gênant dans certains cas.... Le "natif objet" est très pratique pour résoudre des problèmes complexe, mais à mon gout il pousse un peu trop loin la rigidité. Avantage : un programme écrit en Python est assez lisible, même après des années sans y toucher, et n'importe qui connaissant les bases du langage pourra te relire.
Entre deux il y a Ruby que j'ai découvert relativement récemment et qui est pour moi un bon intermédiaire.
# Make your own choice...
Posté par Ellendhel (site web personnel) . Évalué à 4.
Je mets à part les contraintes liées à une intégration avec de l'existant, au partage de connaissances avec des collègues, etc.
Je dirais que le point premier de choix reste " quel est le langage de script avec lequel tu as le plus de facilité ? "
Que ce soit au niveau de la documentation, des exemples, ou de " quelqu'un qui te pousse dans la marmite " il est préférable que tu choisisses selon tes propres critères.
Vu qu'au final, toutes les tâches d'administration peuvent être remplies avec chacun des langages, autant utiliser celui avec lequel on est le plus à l'aise.
Après, il est toujours possible d'en découvrir un ou deux autres une fois que l'on a des bases un peu solides.
Bon, blague à part, le shell c'est tout de même la lingua franca des systèmes *nix alors pourquoi céder aux sirènes des langages modernes ?
bug spotted : les guillemets sont convertis en "e; (du moins lors de la prévisualisation) alors que je n'ai rien demandé ?!
[^] # Re: Make your own choice...
Posté par Dabowl_92 . Évalué à 2.
Grave erreur à mon avis ! Ce sont précisement ces contraintes qui vont faire qu'on ne te laissera pas le choix du langage !
[^] # Re: Make your own choice...
Posté par Ellendhel (site web personnel) . Évalué à 4.
Auquel cas la question ne se pose plus :-)
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Cela dépend de ce que tu fais...
Posté par ybo . Évalué à 1.
[^] # Re: Cela dépend de ce que tu fais...
Posté par Romeo . Évalué à 2.
Imagine ne pas avoir à se taper des grep/sed/awk sur un ps aux pour choper des infos sur les process.
[^] # Re: Cela dépend de ce que tu fais...
Posté par totof2000 . Évalué à 2.
un exemple : créer/agrandir/supprimer des Volume Group/filesystem dans un environnement hétérogène (AIX,Solaris,Linux, HP-UX ayant VxVm ou pas, Vxfs ou pas), de façon plus ou moins automatisée ... Si tu raisonnes pas en "Objet" ça devient vite ingérable.
[^] # Re: Cela dépend de ce que tu fais...
Posté par wilk . Évalué à 1.
Par exemple j'utilise un petit programme python qui me génère des comptes mails. Ensuite, je lance l'interpréteur et je peux faire des choses du genre
m = mail.Mail("wilk", "domain.tld")
m.password = 'monpass'
m.write()
J'ai créé mon nouveau mail, c'est un 'objet' mail, très pratique... A utiliser soit dans l'interpréteur, soit bien sur dans un autre script. Si je veux envoyer un mail aux utilisateurs de tel domain, for mail in get_mails('domain.tld'): sendmail(blalabla, mail.email)...
La même chose pour ma conf apache, ftp etc. J'ai un objet site, site.documentroot=..., site.mod_wsgi=...
Ce n'est pas non plus pour autant une usine à gaz avec une interface graphique etc, ça reste du script d'admin.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# pourquoi ?
Posté par 태 (site web personnel) . Évalué à 3.
Et quand tu programmes, c'est agréable d'avoir des exceptions bien gérées, d'avoir des structures chiadées, d'avoir des idiomes lisibles, d'avoir des itérateurs gratuitement, d'avoir des bibliothèques de parsing xml ou de manipulation d'images ou de logging...
J'ai une aversion sans raison pour Perl, mais j'aime beaucoup programmer en shell (en fait en zsh) et en python. Mais je ne les utilise pas pour les mêmes projets.
Mon algorithme de choix est simple : si je sais faire un prototype en shell, je le fais en zsh. Si ça me pose la moindre difficulté, je le fais en python. Et en général pour l'administration, le shell me suffit.
[^] # Re: pourquoi ?
Posté par totof2000 . Évalué à 2.
Bel exemple de "simplification" qui déforme et conduit à la désinformation ....
en Perl, le tableau
Non, il y a aussi la table de hashage, et tout ce que tu veux, comme en python .... Les différences majeure entre perl et python sont :
- la lisibilité
- la programmation objet qui est native en Python et qui est une glue infame en Perl.
Pour le reste les deux langages font plus ou moins les mêmes choses.
[^] # Re: pourquoi ?
Posté par 태 (site web personnel) . Évalué à 2.
> Non, il y a aussi la table de hashage, et tout ce que tu veux, comme en python
Oui, bien sur. En shell aussi, il y a les tables de hashage. Mais en python, c'est la structure de base, et en plus, tu as tout l'objet que tu veux. En perl, les objets sont des tableaux dévoyés.
[^] # Re: pourquoi ?
Posté par totof2000 . Évalué à 2.
Qu'entends-tu par la ? Quelle est la différence avec Python ?
Pour les objets nous sommes d'accord : je déteste l'approche objet de Perl. J'ai toujours évité, mais à un moment quand tu commences à avoir un truc assez complexe ça devient ingérable.
# BU.SH les bat à plat de couture.
Posté par Mehdi Saada . Évalué à -5.
Voir http://bush.sourceforge.net/bushintro.html
[^] # Re: BU.SH les bat à plat de couture.
Posté par hocwp (site web personnel) . Évalué à 1.
[^] # Re: BU.SH les bat à plat de couture
Posté par Mehdi Saada . Évalué à -3.
[^] # Re: BU.SH les bat à plat de couture
Posté par hocwp (site web personnel) . Évalué à 1.
D'ailleurs la description dit bien que «BUSH scripts are slower to develop than Python programs but are easier to maintain over the lifetime of a project.» Donc si on veut faire quelque chose rapidement BUSH semble moins adapté que le Python (ou le Ruby puisqu'il reprend la même phrase).
[^] # Re: BU.SH les bat à plat de couture
Posté par Jean B . Évalué à 3.
Ben déjà si on pouvais le télécharger ça aiderai par-ce que la le lien de téléchargement est mort.
Ensuite quand on lit ça:
What's Not Complete
* job control - fg, bg, control-z not implemented yet
* user-defined functions - not yet implemented
* creating JVM or .Net bytecode - The open sources compilers should work on most scripts but it hasn't been tested
ça refroidit un peut. Les fonctions c'est relativement utile quoi qu'on en dise ...
Et de tout ce qui est mis en avant il n'y a rien que Python ou Ruby n'offrent pas déjà. Et eux se sont fait une place ce qui signifie du support et un bon gros paquet de bibliothèques a disposition et ils ont une syntaxe et des concepts bien plus sexy.
[^] # Re: BU.SH les bat à plat de couture
Posté par Mehdi Saada . Évalué à -3.
C'est effectivement du point de vue des performances de faire appel à des bibliothèques compilées à chaque fois que c'est possible. Pour une fonction de 4/5 lignes, c'est un embêtant. "BUSH is not suitable for quick-and-dirty scripts" : ça veut dire ce que ça veut dire.
Personnellement, je ne peux pas blairer perl, je hais ça. Je peux pas en lire une seule ligne, la syntaxe est vraiment trop cryptique. Je préfère largement étaler ce que je veux faire en quelques lignes, toute manière le temps de lecture sera égale.
Mais faut pas abuser, on n'est pas obligé de structurer le script, on a quand même le droit de déclarer des variables où on veut.
L'intérêt de BUSH, c'est qu'il encourage(grâce à sa bien-aimée grand-mère Ada ;-) ) la sûreté, la maintenabilité même si le projet devient gros(alors que Perl devient illisible après un certain nombre de ligne(ou 1 pour des personnes comme moi ;))), et si le projet devient trop complexe la traduction sans beaucoup difficulté(pragma(Ada95) aide) vers un executable natif.
C'est bien aussi dans le sens où c'est une solution tout en un : plus besoin d'apprendre le (ba|z)sh, plus php|perl plus Ruby|Python, ah oui plus ECMAscript(c'est plus dur de s'en séparer lui).
Extrait de la liste de diff :
"Website is down for unknown reasons. I'm out of town but I'll bring it
back up when I get the chance. Possibly a denial of service attack like
last month.
Ken B."
il avait dit qu'il redémarrerait le serveur hier soir ... Je ne sais pas ce qu'il en est.
Quant à la syntaxe, je la trouve pas moins "sexy", au contraire apprenant l'Ada j'apprécie beaucoup. On n'a pas la même définition de l'élégance. Concepts ? Tu parles de quoi, du bloat ou de la POO qui n'a pas grand chose à faire là où BUSH est utile ?
[^] # Re: BU.SH les bat à plat de couture
Posté par Mehdi Saada . Évalué à -2.
Le site est de nouveau sur pied. Testez le ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.