Je souhaite faire un script Perl qui devra traiter des fichiers textes :
1. parcourir le fichier ligne =E0 ligne
2. Si une expression r=E9guli=E8re est d=E9tecter, alors lancer un script
J'aimerai votre avis/conseil non pas pour la cr=E9ation de ces 2 =E9tapes; =
mais plut=F4t pour la fa=E7on dont doivent =EAtre stock=E9es la configurati=
on de mon script.
Le traitement risque de durer longtemps vue la volum=E9trie.
En effet, j'ai l'intention d'avoir ces contraintes :
- plusieurs expressions r=E9guli=E8res possibles
- chaque regexp pourra d=E9clencher un ou plusieurs actions (un script ext=
erne par exemple)
- le fichier de configuration pourra =EAtre mis =E0 jour en temps r=E9el ;=
et pendant l'ex=E9cution du script Perl
Conseilleriez vous un fichier de config Xml, un .ini, un hash? ... autre...
Comment feriez-vous pour g=E9rer cette configuration ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Paul Gaborit
À (at) Mon, 16 Sep 2013 12:27:22 -0700 (PDT), Paul écrivait (wrote):
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 - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
À (at) Mon, 16 Sep 2013 12:27:22 -0700 (PDT),
Paul <ernond_paul@yahoo.fr> écrivait (wrote):
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 - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
À (at) Mon, 16 Sep 2013 12:27:22 -0700 (PDT), Paul écrivait (wrote):
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 - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
genomart
Bonsoir,
Dommage de ne pas avoir de retour suite à la réponse de Paul G.
Bonsoir,
Dommage de ne pas avoir de retour suite à la réponse de Paul G.
Dommage de ne pas avoir de retour suite à la réponse de Paul G.
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.
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 , dans le message <wt9fvt4bfgj.fsf@mirabeau.mines-albi.fr>,
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.
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
À (at) 29 Dec 2013 01:09:26 GMT, Nicolas George <nicolas$ écrivait (wrote):
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 - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
À (at) 29 Dec 2013 01:09:26 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
Paul Gaborit , dans le message <wt9fvt4bfgj.fsf@mirabeau.mines-albi.fr>,
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 - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
À (at) 29 Dec 2013 01:09:26 GMT, Nicolas George <nicolas$ écrivait (wrote):
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 - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
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.
Le Sun, 29 Dec 2013 01:09:26 +0000, Nicolas George a écrit:
Paul Gaborit , dans le message <wt9fvt4bfgj.fsf@mirabeau.mines-albi.fr>,
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.
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.
