Fichier de configuration de script Perl
Le
Paul
Bonjour,
Je souhaite faire un script Perl qui devra traiter des fichiers textes :
1. parcourir le fichier ligne à ligne
2. Si une expression régulière est détecter, alors lancer un script
J'aimerai votre avis/conseil non pas pour la création de ces 2 étapes; =
mais plutôt pour la façon dont doivent être stockées la configurati=
on de mon script.
Le traitement risque de durer longtemps vue la volumétrie.
En effet, j'ai l'intention d'avoir ces contraintes :
- plusieurs expressions régulières possibles
- chaque regexp pourra déclencher un ou plusieurs actions (un script ext=
erne par exemple)
- le fichier de configuration pourra être mis à jour en temps réel ;=
et pendant l'exécution du script Perl
Conseilleriez vous un fichier de config Xml, un .ini, un hash? autre
Comment feriez-vous pour gérer cette configuration ?
Merci de votre aide.
Je souhaite faire un script Perl qui devra traiter des fichiers textes :
1. parcourir le fichier ligne à ligne
2. Si une expression régulière est détecter, alors lancer un script
J'aimerai votre avis/conseil non pas pour la création de ces 2 étapes; =
mais plutôt pour la façon dont doivent être stockées la configurati=
on de mon script.
Le traitement risque de durer longtemps vue la volumétrie.
En effet, j'ai l'intention d'avoir ces contraintes :
- plusieurs expressions régulières possibles
- chaque regexp pourra déclencher un ou plusieurs actions (un script ext=
erne par exemple)
- le fichier de configuration pourra être mis à jour en temps réel ;=
et pendant l'exécution du script Perl
Conseilleriez vous un fichier de config Xml, un .ini, un hash? autre
Comment feriez-vous pour gérer cette configuration ?
Merci de votre aide.
Paul
Bon.
Bon.
C'est quoi longtemps ? 1 heure, 1 journée, 1 mois, 1 an... ? Que sont
les volumes ? 1, 10, 100 Go, 1, 10, 100 To... ? Combien de fichiers
sont accessibles simultanément (pour éventuellement parallèliser le
traitement) ?
Pour éviter de les vérifier toutes une par une sur chaque ligne, cela
peut valoir le coup de construire une seule expression rationnelle qui
les réunira toutes avec un "ou"...
Faut-il attendre la fin du processus externe pour continuer
l'exploration ? Faut-il récupérer un résultat (ou un code d'erreur
quelconque) issu de ce processus externe ? Selon les réponses, les
techniques à mettre en œuvre diffèrent...
S'il peut y avoir de nombreux processus externes lancés simultanément en
plus du traitement des fichiers à lire, souhaitez-vous contrôler la
charge de la machine ?
Ça, c'est déjà moins courant. Pour éviter de vérifier régulièrement si
le fichier de configuration à changé ou non, on préfère généralement
prévenir le processus via un signal.
Franchement, la manière dont le fichier est stocké importe peu. Le mieux
consiste à choisir le meilleur compromis entre la facilité d'édition du
fichier et sa lecture par le script. Personnellement, pour un fichier
texte, j'aime bien YAML.
--
Paul Gaborit - Perl en français -
Dommage de ne pas avoir de retour suite à la réponse de Paul G.
Je déconseille vivement un langage où l'espacement est sensitif, surtout
pour un perliste.
Si les exigences de sécurité le permettent, faire le fichier de config en
perl soi-même est très simple et très souple.
Nicolas George
Sauf qu'un fichier de configuration n'est que rarement destiné à être
écrit par le développeur. Le fait que le code soit en Perl (ou en
n'importe quoi d'autres) n'intervient donc pas dans le choix.
Pour "l'espacement sensitif", c'est une question d'habitude et
d'explications. De plus, cet aspect n'intervient que si on utilise une
hiérarchie pour ses données de configuration.
De mon point de vue, c'est bien le pire conseil qu'on puisse donner. Un
fichier de configuration en Perl implique que celui qui l'écrit connaît
Perl (et toutes ses subtilités). Comme c'est rarement le cas, c'est
prendre le risque que l'utilisateur (du fichier de configuration) écrive
n'importe quoi (ou en tous cas, pas ce qu'il croit écrire).
--
Paul Gaborit - Perl en français -
Traditionnellement, $SIG{HUP} d'ailleurs...
Pour être à la mode, le mieux c'est encore JSON.
--
Le droit d'auteur, vraiment c'est pas possible. Un auteur n'a aucun
droit. Je n'ai aucun droit. Je n'ai que des devoirs.
Jean-Luc Godard.