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.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Paul Gaborit
Le #25665012
À (at) Mon, 16 Sep 2013 12:27:22 -0700 (PDT),
Paul
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



Bon.

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 configuration
de mon script.



Bon.

Le traitement risque de durer longtemps vue la volumétrie.



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) ?

En effet, j'ai l'intention d'avoir ces contraintes :
- plusieurs expressions régulières possibles



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"...

- chaque regexp pourra déclencher un ou plusieurs actions (un script
externe par exemple)



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 ?

- le fichier de configuration pourra être mis à jour en temps réel ;
et pendant l'exécution du script Perl



Ç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.

Conseilleriez vous un fichier de config Xml, un .ini, un hash? ... autre...
Comment feriez-vous pour gérer cette configuration ?



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 -
genomart
Le #25898402
Bonsoir,

Dommage de ne pas avoir de retour suite à la réponse de Paul G.
Nicolas George
Le #25898572
Paul Gaborit , dans le message a écrit :
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.



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.
Paul Gaborit
Le #25898742
À (at) 29 Dec 2013 01:09:26 GMT,
Nicolas George
Paul Gaborit , dans le message a écrit :
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.



Je déconseille vivement un langage où l'espacement est sensitif, surtout
pour un perliste.



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.

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.



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 -
espie
Le #25899162
In article Paul Gaborit
- le fichier de configuration pourra être mis à jour en temps réel ;
et pendant l'exécution du script Perl



Ç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.



Traditionnellement, $SIG{HUP} d'ailleurs...
Emmanuel Florac
Le #25911852
Le Sun, 29 Dec 2013 01:09:26 +0000, Nicolas George a écrit:

Paul Gaborit , dans le message a écrit :
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.



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.



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.
Publicité
Poster une réponse
Anonyme