Dans la série "Quel langage utiliser pour ...", je suis dans la
situation suivante:
Je déploie régulièrement un CMS utilisant PHP et MySQL sur des serveurs
Web. J'ai donc pris l'habitude de scripter (en shell) toutes les
opérations. Mais aujourd'hui, l'ensemble devient lourd, et difficilement
maintenable (c'est sans doute dû en partie à ma façon d'écrire en
shell). Du coup, je voudrais tout ré-écrire from scratch, et je me
demande si je devrais ou non changer de langage, et pour quel langage.
Les tâches de ces scripts sont typiquement:
- décompactage d'archives gzippées
- modification de fichiers de configuration
- upload via ftp
- création de scripts de commandes SQL
- requête HTTP (wget)
Je voudrais éventuellement étendre les capacités de ces scripts pour
qu'ils puissent lire des fichiers de configuration, exécuter directement
les scripts SQL, faire des sauvegardes avant upgrade, les rendre portables
vers des systèmes non-Unix (pas vital, toutefois) ...
Pour tout ça, j'ai pensé à Perl ou Python, mais la réputation
d'illisibilité du premier me freine, et l'existence du CPAN ne me pousse
pas vers le second. Sans vouloir provoquer de troll (comment ça "trop
tard" ?), j'aimerais bien avoir l'avis des uns et des autres, et
éventuellement des suggestions d'autres langages ...
comp.editors est le meilleur (mais en anglais), il ne me semble pas déplacé non plus sur les groupes dédiés à Unix si les questions restent d'intérêt général.
-- Thomas Baruchel
ou en macros VI.
Au passage, sur quel groupe VI est en charte?
comp.editors est le meilleur (mais en anglais), il ne me semble pas
déplacé non plus sur les groupes dédiés à Unix si les questions restent
d'intérêt général.
comp.editors est le meilleur (mais en anglais), il ne me semble pas déplacé non plus sur les groupes dédiés à Unix si les questions restent d'intérêt général.
-- Thomas Baruchel
R12y
On Fri, 02 Sep 2005 08:58:20 +0000, Thomas Baruchel wrote:
ou en macros VI.
Au passage, sur quel groupe VI est en charte?
-- SPIP, phpNuke, Plone, opengroupware... c'est bien CPS c'est mieux: http://www.cps-project.org/ Hébergement de sites CPS: http://www.objectis.org/
On Fri, 02 Sep 2005 08:58:20 +0000, Thomas Baruchel wrote:
ou en macros VI.
Au passage, sur quel groupe VI est en charte?
--
SPIP, phpNuke, Plone, opengroupware... c'est bien
CPS c'est mieux: http://www.cps-project.org/
Hébergement de sites CPS: http://www.objectis.org/
Ça consiste en quoi d'être « directement orienté vers les tâches d'administration » ?
Il a des choses que je fais en root, d'autres pas.
Mais tu n'es pas un langage.
--drkm
drkm
Thomas vO writes:
À (at) Fri, 02 Sep 2005 16:43:47 +0200, drkm nous disait (told us):
Je ne vois pas en quoi. L'avantage que je vois à ces langages, c'est la quantité des bibliothèques disponibles (de qualité variable pour ce qui est de Perl, si je me souviens bien). Mais je ne vois pas en quoi les « tâches d'administration » y sont naturelles.
ben sous Perl, c'est naturel, puisque ça a été écrit pour ça...
Ce qui ne suffit pas. Encore faut-il rencontrer ses objectifs. Si je peux reconnaître à Perl des facilités pour l'utilisation des expressions régulières, par exemple, je ne vois pas en quoi les « tâches d'administration » y seraient naturelles.
(Practical Extraction and Report Language) si mes souvenirs sont bons...
Je n'ai pas mon Camel Book sous la main, mais il me semble que Larry Wall y donne d'autres définitions, plus comiques.
--drkm
Thomas vO writes:
À (at) Fri, 02 Sep 2005 16:43:47 +0200,
drkm <usenet@fgeorges.org> nous disait (told us):
Je ne vois pas en quoi. L'avantage que je vois à ces langages,
c'est la quantité des bibliothèques disponibles (de qualité
variable pour ce qui est de Perl, si je me souviens bien). Mais
je ne vois pas en quoi les « tâches d'administration » y sont
naturelles.
ben sous Perl, c'est naturel, puisque ça a été écrit pour
ça...
Ce qui ne suffit pas. Encore faut-il rencontrer ses objectifs.
Si je peux reconnaître à Perl des facilités pour l'utilisation
des expressions régulières, par exemple, je ne vois pas en quoi
les « tâches d'administration » y seraient naturelles.
(Practical Extraction and Report Language) si mes souvenirs sont
bons...
Je n'ai pas mon Camel Book sous la main, mais il me semble que
Larry Wall y donne d'autres définitions, plus comiques.
À (at) Fri, 02 Sep 2005 16:43:47 +0200, drkm nous disait (told us):
Je ne vois pas en quoi. L'avantage que je vois à ces langages, c'est la quantité des bibliothèques disponibles (de qualité variable pour ce qui est de Perl, si je me souviens bien). Mais je ne vois pas en quoi les « tâches d'administration » y sont naturelles.
ben sous Perl, c'est naturel, puisque ça a été écrit pour ça...
Ce qui ne suffit pas. Encore faut-il rencontrer ses objectifs. Si je peux reconnaître à Perl des facilités pour l'utilisation des expressions régulières, par exemple, je ne vois pas en quoi les « tâches d'administration » y seraient naturelles.
(Practical Extraction and Report Language) si mes souvenirs sont bons...
Je n'ai pas mon Camel Book sous la main, mais il me semble que Larry Wall y donne d'autres définitions, plus comiques.
--drkm
Benoit Izac
Bonjour,
le 02/09/2005 à 12:51, Étienne Labaume a écrit dans le message <43182eb5$0$19807$ :
Pour tout ça, j'ai pensé à Perl ou Python, mais la réputation d'illisibilité du premier me freine,
Il est tout à fait envisageable d'écrire du Perl lisible. Il suffit de ne pas être paresseux (exactement comme en C), et de s'imposer des règles de codage -- surtout si vous ne serez pas le seul amené à relire les sources.
Question peut-être triviale: Selon vous, quelles sont ces règles ? Vous avez des pointeurs ?
Pour un bon début :
#!/usr/bin/perl use warnings; use strict; # ici, tu peux commencer à coder
Fu2 là où on en parle. -- Benoit Izac
Bonjour,
le 02/09/2005 à 12:51, Étienne Labaume a écrit
dans le message <43182eb5$0$19807$636a15ce@news.free.fr> :
Pour tout ça, j'ai pensé à Perl ou Python, mais la réputation
d'illisibilité du premier me freine,
Il est tout à fait envisageable d'écrire du Perl lisible. Il suffit
de ne pas être paresseux (exactement comme en C), et de s'imposer des
règles de codage -- surtout si vous ne serez pas le seul amené à
relire les sources.
Question peut-être triviale: Selon vous, quelles sont ces règles ?
Vous avez des pointeurs ?
Pour un bon début :
#!/usr/bin/perl
use warnings;
use strict;
# ici, tu peux commencer à coder
le 02/09/2005 à 12:51, Étienne Labaume a écrit dans le message <43182eb5$0$19807$ :
Pour tout ça, j'ai pensé à Perl ou Python, mais la réputation d'illisibilité du premier me freine,
Il est tout à fait envisageable d'écrire du Perl lisible. Il suffit de ne pas être paresseux (exactement comme en C), et de s'imposer des règles de codage -- surtout si vous ne serez pas le seul amené à relire les sources.
Question peut-être triviale: Selon vous, quelles sont ces règles ? Vous avez des pointeurs ?
Pour un bon début :
#!/usr/bin/perl use warnings; use strict; # ici, tu peux commencer à coder
Fu2 là où on en parle. -- Benoit Izac
Emmanuel Florac
Le Fri, 02 Sep 2005 17:43:33 +0200, drkm a écrit :
je ne vois pas en quoi les « tâches d'administration » y seraient naturelles.
Ouvrir un fichier, le parcourir, le modifier en place ou bien en faisant une sauvegarde automatique, par exemple?
-- Dix grammes d'abstraction valent des tonnes de bricolage. Loi de Booker.
Le Fri, 02 Sep 2005 17:43:33 +0200, drkm a écrit :
je ne vois pas en quoi
les « tâches d'administration » y seraient naturelles.
Ouvrir un fichier, le parcourir, le modifier en place ou bien en faisant
une sauvegarde automatique, par exemple?
--
Dix grammes d'abstraction valent des tonnes de bricolage.
Loi de Booker.
je ne vois pas en quoi les « tâches d'administration » y seraient naturelles.
Ouvrir un fichier, le parcourir, le modifier en place ou bien en faisant une sauvegarde automatique, par exemple?
Je veux bien, mais en quoi cela est-il naturel en Perl ?
--drkm
Emmanuel Florac
Le Sat, 03 Sep 2005 02:46:03 +0200, drkm a écrit :
Je veux bien, mais en quoi cela est-il naturel en Perl ?
C'est naturel parce qu'il y a des raccourcis prévus pour, par exemple
perl -pi bak -e "s/toto/titi/g" monfichier.txt
Qui fait automatiquement la boucle, fait automatiquement une copie, et modifie automatiquement le fichier en place. C'est énormément plus rapide que le même genre de manip faites avec sed ou awk dans un script shell, en plus.
-- Quidquid latine dictum sit, altum sonatur
Le Sat, 03 Sep 2005 02:46:03 +0200, drkm a écrit :
Je veux bien, mais en quoi cela est-il naturel en Perl ?
C'est naturel parce qu'il y a des raccourcis prévus pour, par exemple
perl -pi bak -e "s/toto/titi/g" monfichier.txt
Qui fait automatiquement la boucle, fait automatiquement une copie, et
modifie automatiquement le fichier en place.
C'est énormément plus rapide que le même genre de manip faites avec sed
ou awk dans un script shell, en plus.
Le Sat, 03 Sep 2005 02:46:03 +0200, drkm a écrit :
Je veux bien, mais en quoi cela est-il naturel en Perl ?
C'est naturel parce qu'il y a des raccourcis prévus pour, par exemple
perl -pi bak -e "s/toto/titi/g" monfichier.txt
Qui fait automatiquement la boucle, fait automatiquement une copie, et modifie automatiquement le fichier en place. C'est énormément plus rapide que le même genre de manip faites avec sed ou awk dans un script shell, en plus.
