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 ...
ou en postscript http://public.planetmirror.com/pub/pshttpd/
ou en macros VI.
-- Thomas Baruchel
Étienne Labaume
Le 01-09-2005, Pascal Bourguignon a écrit:
C'est un vrai langage de programmation, ainsi je n'ai aucun problème, aucune limitation venant du langage.
Mais ce qui est pratique avec les scripts shell, c'est d'avoir accés à tous les outils habituels : grep, sed, find, etc Il y a des outils de ce genre en clisp ?
Pas la peine, c'est un "language de shell":
(ext:shell "find .. -exec grep ...|sed ... ")
C'est exactement ce que je voudrais éviter en changeant de langage: tous ces appels à d'autres programme à qui l'on passe des variables en argument. Ça a vite fait de rendre l'ensemble brouillon, et c'est super fragile (un espace, une apostrophe, un `:' ou une virgule dans un nom de variable, et on a vite fait de tout planter). Est-ce que ces appels vont être aussi difficiles à éviter avec un langage comme Perl ou Python qu'avec le Shell ? Est-ce que c'est moi qui ne programme pas proprement en Shell ?
-- Tinou
Le 01-09-2005, Pascal Bourguignon <spam@mouse-potato.com> a écrit:
C'est un vrai langage de programmation, ainsi je n'ai aucun problème,
aucune limitation venant du langage.
Mais ce qui est pratique avec les scripts shell, c'est d'avoir accés à
tous les outils habituels : grep, sed, find, etc
Il y a des outils de ce genre en clisp ?
Pas la peine, c'est un "language de shell":
(ext:shell "find .. -exec grep ...|sed ... ")
C'est exactement ce que je voudrais éviter en changeant de langage: tous
ces appels à d'autres programme à qui l'on passe des variables en
argument. Ça a vite fait de rendre l'ensemble brouillon, et c'est super
fragile (un espace, une apostrophe, un `:' ou une virgule dans un nom de
variable, et on a vite fait de tout planter). Est-ce que ces appels vont
être aussi difficiles à éviter avec un langage comme Perl ou Python
qu'avec le Shell ? Est-ce que c'est moi qui ne programme pas proprement
en Shell ?
C'est un vrai langage de programmation, ainsi je n'ai aucun problème, aucune limitation venant du langage.
Mais ce qui est pratique avec les scripts shell, c'est d'avoir accés à tous les outils habituels : grep, sed, find, etc Il y a des outils de ce genre en clisp ?
Pas la peine, c'est un "language de shell":
(ext:shell "find .. -exec grep ...|sed ... ")
C'est exactement ce que je voudrais éviter en changeant de langage: tous ces appels à d'autres programme à qui l'on passe des variables en argument. Ça a vite fait de rendre l'ensemble brouillon, et c'est super fragile (un espace, une apostrophe, un `:' ou une virgule dans un nom de variable, et on a vite fait de tout planter). Est-ce que ces appels vont être aussi difficiles à éviter avec un langage comme Perl ou Python qu'avec le Shell ? Est-ce que c'est moi qui ne programme pas proprement en Shell ?
-- Tinou
Thomas Baruchel
variable, et on a vite fait de tout planter). Est-ce que ces appels vont être aussi difficiles à éviter avec un langage comme Perl ou Python qu'avec le Shell ? Est-ce que c'est moi qui ne programme pas proprement en Shell ?
Les bibliothèques de fonctions de Perl ou de Python sont susceptibles d'être plus directement orientées vers les tâches qui t'intéressent, donc tu auras probablement moins d'appels extérieurs apparaissant comme tels dans ton propre code.
-- Thomas Baruchel
variable, et on a vite fait de tout planter). Est-ce que ces appels vont
être aussi difficiles à éviter avec un langage comme Perl ou Python
qu'avec le Shell ? Est-ce que c'est moi qui ne programme pas proprement
en Shell ?
Les bibliothèques de fonctions de Perl ou de Python sont susceptibles
d'être plus directement orientées vers les tâches qui t'intéressent, donc
tu auras probablement moins d'appels extérieurs apparaissant comme tels dans
ton propre code.
variable, et on a vite fait de tout planter). Est-ce que ces appels vont être aussi difficiles à éviter avec un langage comme Perl ou Python qu'avec le Shell ? Est-ce que c'est moi qui ne programme pas proprement en Shell ?
Les bibliothèques de fonctions de Perl ou de Python sont susceptibles d'être plus directement orientées vers les tâches qui t'intéressent, donc tu auras probablement moins d'appels extérieurs apparaissant comme tels dans ton propre code.
-- Thomas Baruchel
Étienne Labaume
Le 31-08-2005, Stephane Zuckerman a écrit:
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 ?
et l'existence du CPAN ne me pousse pas vers le second.
Je crois bien qu'il existe un équivalent pour Python, mais j'avoue ne pas avoir vraiment cherché.
Il existe, mais en moins fourni, il me semble.
Au "pire", pourquoi ne pas récrire vos scripts en shell, mais avec cette fois en tête tout ce que ceux-ci sont sensés faire ? [...]
En gros, si dans tous les cas vous devrez apprendre un langage, il me semble utile de se demander si *vraiment* il est impossible d'obtenir un script shelle unifié avec les extensions voulues, qui soit plus performant.
Vous me dites que mon problème, c'est juste d'adopter une bonne méthode d'écriture, quel que soit le langage que j'utilise, c'est ça ? :-)
-- Tinou
Le 31-08-2005, Stephane Zuckerman <szuckerm@etu.utc.fr> a écrit:
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 ?
et l'existence du CPAN ne me pousse pas vers le second.
Je crois bien qu'il existe un équivalent pour Python, mais j'avoue ne pas
avoir vraiment cherché.
Il existe, mais en moins fourni, il me semble.
Au "pire", pourquoi ne pas récrire vos scripts en shell, mais avec cette
fois en tête tout ce que ceux-ci sont sensés faire ?
[...]
En gros, si dans tous les cas vous devrez apprendre un langage, il me
semble utile de se demander si *vraiment* il est impossible d'obtenir un
script shelle unifié avec les extensions voulues, qui soit plus
performant.
Vous me dites que mon problème, c'est juste d'adopter une bonne méthode
d'écriture, quel que soit le langage que j'utilise, c'est ça ? :-)
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 ?
et l'existence du CPAN ne me pousse pas vers le second.
Je crois bien qu'il existe un équivalent pour Python, mais j'avoue ne pas avoir vraiment cherché.
Il existe, mais en moins fourni, il me semble.
Au "pire", pourquoi ne pas récrire vos scripts en shell, mais avec cette fois en tête tout ce que ceux-ci sont sensés faire ? [...]
En gros, si dans tous les cas vous devrez apprendre un langage, il me semble utile de se demander si *vraiment* il est impossible d'obtenir un script shelle unifié avec les extensions voulues, qui soit plus performant.
Vous me dites que mon problème, c'est juste d'adopter une bonne méthode d'écriture, quel que soit le langage que j'utilise, c'est ça ? :-)
-- Tinou
Emmanuel Florac
Le Fri, 02 Sep 2005 10:37:11 +0000, Étienne Labaume a écrit :
C'est exactement ce que je voudrais éviter en changeant de langage: tous ces appels à d'autres programme à qui l'on passe des variables en argument. Ça a vite fait de rendre l'ensemble brouillon, et c'est super fragile (un espace, une apostrophe, un `:' ou une virgule dans un nom de variable, et on a vite fait de tout planter). Est-ce que ces appels vont être aussi difficiles à éviter avec un langage comme Perl ou Python qu'avec le Shell ? Est-ce que c'est moi qui ne programme pas proprement en Shell ?
Shell est explicitement conçu pour être une glu entre les outils du système, donc c'est comme ça.... Par contre en Perl et Python, tu as des fonctions internes pour manipuler les chaînes et les fichiers, donc tu ne dois pas avoir à utiliser les ls, grep, sed et awk... Par contre pour certaines choses tu peux avoir besoin de modules externes supplémentaires, et parfois il peut être plus simple d'appeler directement une commande système.
-- In girum imus nocte ecce et consumimur igni
Le Fri, 02 Sep 2005 10:37:11 +0000, Étienne Labaume a écrit :
C'est exactement ce que je voudrais éviter en changeant de langage: tous
ces appels à d'autres programme à qui l'on passe des variables en
argument. Ça a vite fait de rendre l'ensemble brouillon, et c'est super
fragile (un espace, une apostrophe, un `:' ou une virgule dans un nom de
variable, et on a vite fait de tout planter). Est-ce que ces appels vont
être aussi difficiles à éviter avec un langage comme Perl ou Python
qu'avec le Shell ? Est-ce que c'est moi qui ne programme pas proprement
en Shell ?
Shell est explicitement conçu pour être une glu entre les outils du
système, donc c'est comme ça.... Par contre en Perl et
Python, tu as des fonctions internes pour manipuler les chaînes et les
fichiers, donc tu ne dois pas avoir à utiliser les ls, grep, sed et
awk... Par contre pour certaines choses tu peux avoir besoin de modules
externes supplémentaires, et parfois il peut être plus simple d'appeler
directement une commande système.
Le Fri, 02 Sep 2005 10:37:11 +0000, Étienne Labaume a écrit :
C'est exactement ce que je voudrais éviter en changeant de langage: tous ces appels à d'autres programme à qui l'on passe des variables en argument. Ça a vite fait de rendre l'ensemble brouillon, et c'est super fragile (un espace, une apostrophe, un `:' ou une virgule dans un nom de variable, et on a vite fait de tout planter). Est-ce que ces appels vont être aussi difficiles à éviter avec un langage comme Perl ou Python qu'avec le Shell ? Est-ce que c'est moi qui ne programme pas proprement en Shell ?
Shell est explicitement conçu pour être une glu entre les outils du système, donc c'est comme ça.... Par contre en Perl et Python, tu as des fonctions internes pour manipuler les chaînes et les fichiers, donc tu ne dois pas avoir à utiliser les ls, grep, sed et awk... Par contre pour certaines choses tu peux avoir besoin de modules externes supplémentaires, et parfois il peut être plus simple d'appeler directement une commande système.
-- In girum imus nocte ecce et consumimur igni
drkm
Thomas Baruchel writes:
Les bibliothèques de fonctions de Perl ou de Python sont susceptibles d'être plus directement orientées vers les tâches qui t'intéressent
Plus directement par rapport à quoi ?
--drkm
Thomas Baruchel writes:
Les bibliothèques de fonctions de Perl ou de Python sont susceptibles
d'être plus directement orientées vers les tâches qui t'intéressent
Les bibliothèques de fonctions de Perl ou de Python sont susceptibles d'être plus directement orientées vers les tâches qui t'intéressent
Plus directement par rapport à quoi ?
--drkm
Thomas Baruchel
Les bibliothèques de fonctions de Perl ou de Python sont susceptibles d'être plus directement orientées vers les tâches qui t'intéressent
Plus directement par rapport à quoi ?
par rapport d'abord à un shell, lequel n'est pas nativement fait pour manipuler des chaînes, des données, etc., ensuite par rapport à d'autres langages de haut niveau (ceux dont il a beaucoup été question par ailleurs) lesquels ne sont pas directement orientés vers les tâches d'administration, lesquelles sont en revanche particulièrement naturelles en perl ou en python. Cela devrait leur donner un léger avantage en terme de simplicité de code, ni plus ni moins.
-- Thomas Baruchel
Les bibliothèques de fonctions de Perl ou de Python sont susceptibles
d'être plus directement orientées vers les tâches qui t'intéressent
Plus directement par rapport à quoi ?
par rapport d'abord à un shell, lequel n'est pas nativement fait
pour manipuler des chaînes, des données, etc., ensuite par rapport
à d'autres langages de haut niveau (ceux dont il a beaucoup été
question par ailleurs) lesquels ne sont pas directement orientés
vers les tâches d'administration, lesquelles sont en revanche
particulièrement naturelles en perl ou en python. Cela devrait
leur donner un léger avantage en terme de simplicité de code,
ni plus ni moins.
Les bibliothèques de fonctions de Perl ou de Python sont susceptibles d'être plus directement orientées vers les tâches qui t'intéressent
Plus directement par rapport à quoi ?
par rapport d'abord à un shell, lequel n'est pas nativement fait pour manipuler des chaînes, des données, etc., ensuite par rapport à d'autres langages de haut niveau (ceux dont il a beaucoup été question par ailleurs) lesquels ne sont pas directement orientés vers les tâches d'administration, lesquelles sont en revanche particulièrement naturelles en perl ou en python. Cela devrait leur donner un léger avantage en terme de simplicité de code, ni plus ni moins.
par rapport d'abord à un shell, lequel n'est pas nativement fait pour manipuler des chaînes, des données, etc., ensuite par rapport à d'autres langages de haut niveau (ceux dont il a beaucoup été question par ailleurs) lesquels ne sont pas directement orientés vers les tâches d'administration,
Ça consiste en quoi d'être « directement orienté vers les tâches d'administration » ?
lesquelles sont en revanche particulièrement naturelles en perl ou en python.
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.
--drkm
Thomas Baruchel writes:
par rapport d'abord à un shell, lequel n'est pas nativement fait
pour manipuler des chaînes, des données, etc., ensuite par rapport
à d'autres langages de haut niveau (ceux dont il a beaucoup été
question par ailleurs) lesquels ne sont pas directement orientés
vers les tâches d'administration,
Ça consiste en quoi d'être « directement orienté vers les
tâches d'administration » ?
lesquelles sont en revanche
particulièrement naturelles en perl ou en python.
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.
par rapport d'abord à un shell, lequel n'est pas nativement fait pour manipuler des chaînes, des données, etc., ensuite par rapport à d'autres langages de haut niveau (ceux dont il a beaucoup été question par ailleurs) lesquels ne sont pas directement orientés vers les tâches d'administration,
Ça consiste en quoi d'être « directement orienté vers les tâches d'administration » ?
lesquelles sont en revanche particulièrement naturelles en perl ou en python.
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.
--drkm
Thomas vO
bonjour,
À (at) Fri, 02 Sep 2005 16:43:47 +0200, drkm nous disait (told us):
Thomas Baruchel writes:
lesquelles sont en revanche particulièrement naturelles en perl ou en python.
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... (Practical Extraction and Report Language) si mes souvenirs sont bons...
<troll ?>mais on peut empêcher personne d'essayer de faire de l'administration avec vébédotenet et wine...</troll !>
-- Thomas vO - <http://perso.enstimac.fr/~vanouden/>
bonjour,
À (at) Fri, 02 Sep 2005 16:43:47 +0200,
drkm <usenet@fgeorges.org> nous disait (told us):
Thomas Baruchel writes:
lesquelles sont en revanche
particulièrement naturelles en perl ou en python.
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... (Practical Extraction and Report Language) si mes souvenirs sont
bons...
<troll ?>mais on peut empêcher personne d'essayer de faire de
l'administration avec vébédotenet et wine...</troll !>
--
Thomas vO - <http://perso.enstimac.fr/~vanouden/>
À (at) Fri, 02 Sep 2005 16:43:47 +0200, drkm nous disait (told us):
Thomas Baruchel writes:
lesquelles sont en revanche particulièrement naturelles en perl ou en python.
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... (Practical Extraction and Report Language) si mes souvenirs sont bons...
<troll ?>mais on peut empêcher personne d'essayer de faire de l'administration avec vébédotenet et wine...</troll !>
-- Thomas vO - <http://perso.enstimac.fr/~vanouden/>
