Bonjour. Je reviens sur le sujet du require abordé dans un récent fil
parce que je n'y réussi pas.
Rappel : soit un script principal en perl (main.cgi) souhaitant utiliser
toutes les déclarations (constantes et variabbles) d'un fichier
modifiable par l'utilisateur (config.cgi). Je souhaitais incorporer
config.cgi dans main.cgi via une ligne "require 'config.cgi';", mais ça
me pose quelque problème. A noter que je teste sous ça dans un
environnement avec Perl Express comme IDE, ActivePerl comme interpréteur
Perl, le tout sous Windows.
Le souci vient du fait que je souhaite aussi mettre une ligne "use
strict;" et lancer le script avec warnings (-w) durant le développement.
Or, lorsque je vérifie la syntaxe dans PerlExpress (F12) avec "use
strict;" actif, le require semble ne pas fonctionner : j'obtiens une
erreur : "Global symbol '$STYPE' requires explicit package name at
main.cgi line 23." sur la première variable devant provenr de
config.cgi.
Si je retire "use strict;", le lien à config.cgi semble marcher (pas
d'erreur de var non déclarée), mais cette fois, c'est le -w qui me met
des warnings de type : "Name 'main::STATCOL' used only once: possible
typo at main.cgi line 240.".
Si je retire "use strict;" et "-w", tout va bien !
Ma question est donc : comment faire accepter ce "require
'config.cgi';" avec "use strict;" et le switch "-w" ?
Une solution consiste à *définir* vos variables de configuration *avant* de faire appel au 'require' (ça permet en plus de fixer des valeurs par défaut).
Hé hé 14h33 contre 14h02 pour le post du fil où j'arrive à la même chose (sauf our des deux côté pour satisfaire au use strict ds les deux fichiers) : j'ai donc gagné :-))))))))) Yeeeeeeeeeeeeeesssssssssssssss !
Allez, plus sérieusement, une question pour la route : Est-ce que le chemin vers config.cgi ne peut pas être relatif à main.cgi (sans revenir au racine) : soit "require 'config.cgi';" tout bêtement. Ca marche ici sur activeperl sous win.
Merci
In article <r77j6uwm3p.fsf@vaugirard.enstimac.fr>,
Paul.Gaborit@invalid.invalid says...
Une solution consiste à *définir* vos variables de configuration
*avant* de faire appel au 'require' (ça permet en plus de fixer des
valeurs par défaut).
Hé hé 14h33 contre 14h02 pour le post du fil où j'arrive à la même chose
(sauf our des deux côté pour satisfaire au use strict ds les deux
fichiers) : j'ai donc gagné :-))))))))) Yeeeeeeeeeeeeeesssssssssssssss !
Allez, plus sérieusement, une question pour la route : Est-ce que le
chemin vers config.cgi ne peut pas être relatif à main.cgi (sans revenir
au racine) : soit "require 'config.cgi';" tout bêtement. Ca marche ici
sur activeperl sous win.
Une solution consiste à *définir* vos variables de configuration *avant* de faire appel au 'require' (ça permet en plus de fixer des valeurs par défaut).
Hé hé 14h33 contre 14h02 pour le post du fil où j'arrive à la même chose (sauf our des deux côté pour satisfaire au use strict ds les deux fichiers) : j'ai donc gagné :-))))))))) Yeeeeeeeeeeeeeesssssssssssssss !
Allez, plus sérieusement, une question pour la route : Est-ce que le chemin vers config.cgi ne peut pas être relatif à main.cgi (sans revenir au racine) : soit "require 'config.cgi';" tout bêtement. Ca marche ici sur activeperl sous win.
Merci
Paul Gaborit
À (at) Thu, 16 Mar 2006 15:48:56 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
Je ne suis pas d'accord.
Ça se défend... mais il y a du pour et du contre ;-)
En fait cela dépend vraiment de la nature du programme et du ou des fichiers de configuration.
Déjà, si il y a un fichier de configuration, cela suppose un utilisateur chevronné (Mme Michu ne sait pas modifier un fichier).
Tant qu'il a une syntaxe maîtrisée, on peut imaginer qu'il existe une interface plus simple (pour Mmme Michu) qui ne cassera pas tout si quelqu'un utilise des choses plus évoluées de la syntaxe choisie.
Mais si c'est du Perl (quelconque donc), je vois mal comment une interface graphique pourrait utiliser ce format dans *tous* les cas. Donc on gagne en puissance expressive ce qu'on perd en facilité. La solution étant alors d'imaginer une configuration à deux fichiers : l'un simple (voire simpliste) et l'autre en Perl (question: lequel des deux est prioritaire sur l'autre ?).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Thu, 16 Mar 2006 15:48:56 +0000 (UTC),
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
Je ne suis pas d'accord.
Ça se défend... mais il y a du pour et du contre ;-)
En fait cela dépend vraiment de la nature du programme et du ou des
fichiers de configuration.
Déjà, si il y a un fichier de configuration, cela suppose un
utilisateur chevronné (Mme Michu ne sait pas modifier un
fichier).
Tant qu'il a une syntaxe maîtrisée, on peut imaginer qu'il existe une
interface plus simple (pour Mmme Michu) qui ne cassera pas tout si
quelqu'un utilise des choses plus évoluées de la syntaxe choisie.
Mais si c'est du Perl (quelconque donc), je vois mal comment une
interface graphique pourrait utiliser ce format dans *tous* les
cas. Donc on gagne en puissance expressive ce qu'on perd en
facilité. La solution étant alors d'imaginer une configuration à deux
fichiers : l'un simple (voire simpliste) et l'autre en Perl (question:
lequel des deux est prioritaire sur l'autre ?).
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Thu, 16 Mar 2006 15:48:56 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
Je ne suis pas d'accord.
Ça se défend... mais il y a du pour et du contre ;-)
En fait cela dépend vraiment de la nature du programme et du ou des fichiers de configuration.
Déjà, si il y a un fichier de configuration, cela suppose un utilisateur chevronné (Mme Michu ne sait pas modifier un fichier).
Tant qu'il a une syntaxe maîtrisée, on peut imaginer qu'il existe une interface plus simple (pour Mmme Michu) qui ne cassera pas tout si quelqu'un utilise des choses plus évoluées de la syntaxe choisie.
Mais si c'est du Perl (quelconque donc), je vois mal comment une interface graphique pourrait utiliser ce format dans *tous* les cas. Donc on gagne en puissance expressive ce qu'on perd en facilité. La solution étant alors d'imaginer une configuration à deux fichiers : l'un simple (voire simpliste) et l'autre en Perl (question: lequel des deux est prioritaire sur l'autre ?).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Nicolas George
Asterbing wrote in message :
In article , Tiens, pourquoi pas un format à la manière des ancien ini de Win avec
[section] name=value
Sois moderne :
<section> <name>value</name> </section>
Asterbing wrote in message
<MPG.1e83afcbb1e664b7989798@news.tiscali.fr>:
In article <r73bhiwlk4.fsf@vaugirard.enstimac.fr>,
Tiens, pourquoi pas un format à la manière des ancien
ini de Win avec
À (at) Thu, 16 Mar 2006 17:47:22 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
Asterbing wrote in message :
In article , Tiens, pourquoi pas un format à la manière des ancien ini de Win avec
[section] name=value
Sois moderne :
<section> <name>value</name> </section>
Yep ! Il faut donc utiliser XML::Simple qui est fait pour ça ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Nicolas George
Paul Gaborit wrote in message :
Tant qu'il a une syntaxe maîtrisée, on peut imaginer qu'il existe une interface plus simple (pour Mmme Michu) qui ne cassera pas tout si quelqu'un utilise des choses plus évoluées de la syntaxe choisie.
Mais si c'est du Perl (quelconque donc), je vois mal comment une interface graphique pourrait utiliser ce format dans *tous* les cas. Donc on gagne en puissance expressive ce qu'on perd en facilité. La solution étant alors d'imaginer une configuration à deux fichiers : l'un simple (voire simpliste) et l'autre en Perl (question: lequel des deux est prioritaire sur l'autre ?).
On peut envisager une autre solution : le fichier est parsé par perl, et donc chargé dans l'application. Il donne un certain jeu de valeurs. Ces valeurs ont peut-être été calculées de manière complexe, mais l'application ne le sait pas. Plus tard, l'application ré-écrit entièrement la config, en fixant les valeurs. Ainsi, quelque chose du style :
set directory => "$ENV{HOME}/my_things";
devient :
set directory => "/home/toto/my_things";
Il suffit alors d'une option pour désactiver la ré-écriture du fichier de config, et les deux types d'utilisateurs peuvent cohabiter.
Paul Gaborit wrote in message <r7u09yuw5z.fsf@vaugirard.enstimac.fr>:
Tant qu'il a une syntaxe maîtrisée, on peut imaginer qu'il existe une
interface plus simple (pour Mmme Michu) qui ne cassera pas tout si
quelqu'un utilise des choses plus évoluées de la syntaxe choisie.
Mais si c'est du Perl (quelconque donc), je vois mal comment une
interface graphique pourrait utiliser ce format dans *tous* les
cas. Donc on gagne en puissance expressive ce qu'on perd en
facilité. La solution étant alors d'imaginer une configuration à deux
fichiers : l'un simple (voire simpliste) et l'autre en Perl (question:
lequel des deux est prioritaire sur l'autre ?).
On peut envisager une autre solution : le fichier est parsé par perl, et
donc chargé dans l'application. Il donne un certain jeu de valeurs. Ces
valeurs ont peut-être été calculées de manière complexe, mais l'application
ne le sait pas. Plus tard, l'application ré-écrit entièrement la config, en
fixant les valeurs. Ainsi, quelque chose du style :
set directory => "$ENV{HOME}/my_things";
devient :
set directory => "/home/toto/my_things";
Il suffit alors d'une option pour désactiver la ré-écriture du fichier de
config, et les deux types d'utilisateurs peuvent cohabiter.
Tant qu'il a une syntaxe maîtrisée, on peut imaginer qu'il existe une interface plus simple (pour Mmme Michu) qui ne cassera pas tout si quelqu'un utilise des choses plus évoluées de la syntaxe choisie.
Mais si c'est du Perl (quelconque donc), je vois mal comment une interface graphique pourrait utiliser ce format dans *tous* les cas. Donc on gagne en puissance expressive ce qu'on perd en facilité. La solution étant alors d'imaginer une configuration à deux fichiers : l'un simple (voire simpliste) et l'autre en Perl (question: lequel des deux est prioritaire sur l'autre ?).
On peut envisager une autre solution : le fichier est parsé par perl, et donc chargé dans l'application. Il donne un certain jeu de valeurs. Ces valeurs ont peut-être été calculées de manière complexe, mais l'application ne le sait pas. Plus tard, l'application ré-écrit entièrement la config, en fixant les valeurs. Ainsi, quelque chose du style :
set directory => "$ENV{HOME}/my_things";
devient :
set directory => "/home/toto/my_things";
Il suffit alors d'une option pour désactiver la ré-écriture du fichier de config, et les deux types d'utilisateurs peuvent cohabiter.
Asterbing
In article , says...
À (at) Thu, 16 Mar 2006 17:47:22 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
Asterbing wrote in message :
In article , Tiens, pourquoi pas un format à la manière des ancien ini de Win avec
[section] name=value
Sois moderne :
<section> <name>value</name> </section>
Yep ! Il faut donc utiliser XML::Simple qui est fait pour ça ;-)
Ouais, mais alors on retombe dans le cas d'un fichier de config imbuvable pour Mme Michu, alors que le format ini (dit Win-ini l'ourson) semble plus intuitif et est donc attaquable aussi bien à la mimine que via eventuelle GUI.
In article <r7lkvauvax.fsf@vaugirard.enstimac.fr>,
Paul.Gaborit@invalid.invalid says...
À (at) Thu, 16 Mar 2006 17:47:22 +0000 (UTC),
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
Asterbing wrote in message
<MPG.1e83afcbb1e664b7989798@news.tiscali.fr>:
In article <r73bhiwlk4.fsf@vaugirard.enstimac.fr>,
Tiens, pourquoi pas un format à la manière des ancien
ini de Win avec
[section]
name=value
Sois moderne :
<section>
<name>value</name>
</section>
Yep ! Il faut donc utiliser XML::Simple qui est fait pour ça ;-)
Ouais, mais alors on retombe dans le cas d'un fichier de config
imbuvable pour Mme Michu, alors que le format ini (dit Win-ini l'ourson)
semble plus intuitif et est donc attaquable aussi bien à la mimine que
via eventuelle GUI.
À (at) Thu, 16 Mar 2006 17:47:22 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
Asterbing wrote in message :
In article , Tiens, pourquoi pas un format à la manière des ancien ini de Win avec
[section] name=value
Sois moderne :
<section> <name>value</name> </section>
Yep ! Il faut donc utiliser XML::Simple qui est fait pour ça ;-)
Ouais, mais alors on retombe dans le cas d'un fichier de config imbuvable pour Mme Michu, alors que le format ini (dit Win-ini l'ourson) semble plus intuitif et est donc attaquable aussi bien à la mimine que via eventuelle GUI.
