Forum Linux.général [Programmation] Shell / Perl / Python

Posté par  .
Étiquettes : aucune
2
28
avr.
2009
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.
  • # melting pot...

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    Rigolo de que souvent, ceux qui font du bash se retrouvent souvent à faire du bash perlé (avec des "perl -pe" à tout bout de champs), et que ceux qui font du perl usent et abusent des system() pour finir avec du perl bashé.

    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  . Évalué à 1.

      melting pot bash/gawk ainsi que tous les autres outils (sed, grep, expect...) pour ma part, mais il est vrai que je fais plutôt de l'admin de réseaux. Je n'ai jamais eu le besoin de me mettre à perl même si j'en comprend l'intérêt.

      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  . Évalué à 2.

    disons que d'un point de vue implantation ; le perl l'emporte sur python.

    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  . Évalué à 2.

      J'espère que les pythonneux vont arriver à me convaincre à m'investir dans ce langage !

      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  (site web personnel) . Évalué à 4.

    Quel est donc selon vous le langage le plus apte pour une administration système ? Perl, Python ou juste du shell ?

    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  . Évalué à 2.

      Je mets à part les contraintes liées à une intégration avec de l'existant, au partage de connaissances avec des collègues, etc.

      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  (site web personnel) . Évalué à 4.

        Grave erreur à mon avis ! Ce sont précisement ces contraintes qui vont faire qu'on ne te laissera pas le choix du langage !

        Auquel cas la question ne se pose plus :-)
  • # Commentaire supprimé

    Posté par  . Évalué à 2.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Cela dépend de ce que tu fais...

      Posté par  . Évalué à 1.

      Oui, mais justement, où trouver un intérêt dans la POO en administration système ?
      • [^] # Re: Cela dépend de ce que tu fais...

        Posté par  . Évalué à 2.

        Demande à Microsoft pourquoi powershell.
        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  . Évalué à 2.

        "administration système " ... c'est vague ....

        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  . Évalué à 1.

        Tout dépend de ce que tu fait comme administration !

        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  . Évalué à 2.

        Ce commentaire a été supprimé par l’équipe de modération.

  • # pourquoi ?

    Posté par  (site web personnel) . Évalué à 3.

    Pour moi, la différence entre ces langages de script, c'est les structures de données. Pour simplifier outrancièrement, en shell, la structure de données, c'est la chaîne ; en Perl, le tableau ; en python, la table de hashage et tout ce que tu veux.

    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  . Évalué à 2.

      Pour moi, la différence entre ces langages de script, c'est les structures de données. Pour simplifier outrancièrement, en shell, la structure de données, c'est la chaîne ; en Perl, le tableau ; en python, la table de hashage et tout ce que tu veux.
      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.

        >> en Perl, le tableau
        > 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  . Évalué à 2.

          Mais en python, c'est la structure de base

          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  . Évalué à -5.

    Perl, Python, Ruby et autre zsh vont se rhabiller devant BUSH(Business Shell) et AdaScript.
    Voir http://bush.sourceforge.net/bushintro.html
    • [^] # Re: BU.SH les bat à plat de couture.

      Posté par  (site web personnel) . Évalué à 1.

      Tu peux argumenter ?
      • [^] # Re: BU.SH les bat à plat de couture

        Posté par  . Évalué à -3.

        Tu es allé voir sur http://bush.sourceforge.net ? Tout est expliqué dessus. Y compris les comparaisons avec Perl, Ruby, Python, Bash, Java/J2EE. C'est bluffant, je ne comprend pas pourquoi personne ne s'y intéresse plus que ça(dans le monde du libre je veux dire).
        • [^] # Re: BU.SH les bat à plat de couture

          Posté par  (site web personnel) . Évalué à 1.

          Bien sûr que je l'ai lu. C'est juste que tu aurais pu ajouter quelques lignes dans ton commentaire expliquant pourquoi Perl, Ruby... pouvaient aller se rhabiller plutôt que de balancer une affirmation comme cela.
          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  . Évalué à 3.

          je ne comprend pas pourquoi personne ne s'y intéresse plus que ça
          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  . Évalué à -3.

            Pour les fonctions, ce que j'ai compris c'est que pour l'auteur, il est préférable d'implémenter les fonctions voulues sous forme de package compilés, que l'on ajoute à BUSH : http://bush.sourceforge.net/bushdetails.html#builtin
            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  . Évalué à -2.

              Désolé je sais pas comment ça se fait. Un modérateur peut arranger ça s'il vous plaie ? Merci.
              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.