Appel d'une sous routine dans autre script

Salut,

Je veux appeller plusieurs fois une sous-routine contenue dans un fichier externe (qui par ailleurs fait d'autres choses).

J'ai vu que la commande "require" me permettait effectivement de charger le fichier afin d'accéder à la sous routine en appelant &maSousRoutine.

Mon problème c'est que le require semble provoquer l'exécution du script externe, et en plus il reçoit les arguments du premier script... Moi je ne veux que charger le fichier pour accéder à la sous routine et lui passer les arguments au moment de l'appel. Comment faire ?

Il Faut nous montrer du code.

Citation:

---

Envoyé par djibril

Il Faut nous montrer du code.

---

Ben c'est simple, j'ai script1.pl et script2.pl :

script1.pl :

Code:

---

1 2 3 4 5 6 7 8

require "script2.pl"   foreach (...) { @args = (....); &maSousRoutine(@args); }

---

script2.pl

Code:

---

1 2 3 4 5 6

[...plein de choses qui n'ont rien à voir...] sub maSousRoutine { my ($arg1, $arg2) = ($_[0], ($_[1]); [fait quelque chose avec $arg1 et $arg2] }

---

Et donc le souci c'est que lorsque j'appelle require "script2.pl" la partie de code qui n'a rien à voir est exécutée avec les arguments de script1.pl.
Donc deux questions :
- est-il possible de faire en sorte de ne pas l'exécuter ?
- est-il possible, si elle s'exécute, de lui transmettre des arguments autres que ceux passés à script1.pl ?

Je pense qu'il faut plutôt utiliser use non ?

Mais j'avoue que je ne l'ai que très rarement implémenté... donc je ne vais pas plus m'avancer...

Citation:

---

Envoyé par Alek-C

Je pense qu'il faut plutôt utiliser use non ?

Mais j'avoue que je ne l'ai que très rarement implémenté... donc je ne vais pas plus m'avancer...

---

J'ai essayé use mais ça n'avais pas l'aire de marcher en spécifiant le chemin de fichier .pl.

J'ai dit une connerie, donc oublie :)

Après vérification, use, tout comme require, charge le code du script appelé, donc si tu as du code en dehors de fonction, ben il sera appelé dans tous les cas...

Je ne sais pas si tu peux charger un perl sans exécuter son code...

edit: tu devrais peut-être sortir toutes les fonctions communes dans un 3ème fichier ?

Citation:

---

Envoyé par Alek-C

tu devrais peut-être sortir toutes les fonctions communes dans un 3ème fichier ?

---

C'est effectivement ce que j'ai fait...mais par curiosité je maintiens ma question car le fonctionnement du require ne me semble pas très logique.

use va charger le fichier au moment de la compilation, pas du run time.
require va ne charger le fichier qu'au moment du run.

Code:

---

1 2 3 4

if (condition) { require "fichier.pm" }

---

Dans ce cas, fichier.pm n'est appellé que si condition est vrai.

Avec require, le code inclu doit être compilé qu'au runtime donc c'est peut-être plus lent.

Globalement pas de différence entre les deux à moins d'avouir un besoin spécifique. Perdo j'utilise "use" sauf cas de chargement conditionnel.



Quand au mode de fonctionnement de require, il est parfaitement clair. Si tu inclus un fichier, le code est exécuté. Si le code déclare juste des fonctions comme c'est souvent le cas, du coup tu as chargé cse fonction dans ton env et tu peux les utiliser.
Je ne comprend pas ce qui te pose problème, c'est de toute façon le comportement normal du include en C aussi ou en PHP ou en ...

'use' c'est quand tu utilises des packages.

Si ton fichier 'script2.pl' ne contient *que* des fonctions, et qu'il n'est pas "autonome" (dans le sens où tu peux avoir script3.pl qui requière une fonction de script2.pl, etc.), tu peux le transformer en package.

Pour ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#!/usr/bin/perl -w   package MonPackage;   use strict;   sub func1() { [...] }   [...]   1;

---

Il faut que ton fichier se nomme *exactement* MonPackage.pm, et il ne faut surtout pas oublier le "1;" à la fin de ce dernier.

Ensuite, dans 'script1.pl', tu peux faire ça :

Code:

---

1 2 3 4 5 6 7

#!/usr/bin/perl -w   use MonPackage;   [...] &func1();

---

Ce n'est pas exactement ce que tu demandais, mais c'est ce qui pour moi s'en rapproche le plus.