Discussion :

[Krys006]

Bonjour,

Je souhaite lancer de manière automatisée plusieurs scripts perl les uns après les autres, sous Windows XP pro.

La 1ère solution (qui fonctionne bien) est de les lancer à des heures précises en utilisant le gestionnaire de tâches de Windows.

Le problème est que le 2eme script doit être lancé une fois le 1er script terminé.

J'ai pensé résoudre le problème en utilisant les id des processus. J'ai testé le module Win32 :: Process :: List, il fournit en effet la liste des processus en exécution. Mais, lorsqu'un script perl est en train de s'exécuter, ce que l'on a comme information sur le processus c'est uniquement "perl.exe" et son id.

Y a-t-il un moyen d'obtenir précisément le nom du script qui s'exécute ?

Mais ce n'est peut-être pas la bonne voie.

Si quelqu'un a déjà résolu ce genre de problème, je serai intéressé par les solutions proposées.

Merci d'avance.

Krys006

[Lolo78]

Pourquoi ne pas simplement enchaîner les différents programmes dans un script qui ne continue et lance le programme2 que quand le programme1 lui a rendu la main?

[Krys006]

J'ai pensé en premier à cette possibilité. Mais en procédant ainsi, le script principal est dépendant du script 1. En effet le script 1 télécharge des données à partir d'un serveur.

Quand tout se passe bien, le temps pour effectuer cette tâche est à peu près constant. Mais quand le temps de fonctionnement du script 1 se prolonge à cause de retard possible dans le téléchargement, voire quand il se bloque, le script principal est bloqué lui aussi.

Or, je souhaiterai garder un contrôle externe sur les scripts à exécuter.

Ainsi, si le temps imparti pour le script 1 est dépassé et que celui-ci est toujours lancé, le script principal le ferme et le relance, puis se ferme lui-même. Si le script 1 est terminé, alors le script principal lance le script 2, puis se ferme lui-même.

Au cas où ce scénario se produirait plusieurs fois, le script principal garde le contrôle sur les autres scripts en s'exécutant toutes les X minutes en tant que tâche programmée.

C'est la raison pour laquelle je préférerai avoir accès aux scripts en cours de fonctionnement.

Mais ce n'est peut-être pas la bonne façon de procéder ?

[Lolo78]

Hum, il faut probablement utiliser du multi-process (ou du multi-thread).

De cette façon, le père peut garder le contrôle du fils et savoir quand il se termine.

[Krys006]

Merci pour ces propositions. Je ne connais pas bien le fonctionnement des scripts perl en mode multi-thread, alors je vais creuser un peu.
S'il existe un bon tutoriel sur la question, je suis preneur. Cependant, est-il facile de transformer un script classique en script multi-thread s'il n'a
pas été conçu pour fonctionner ainsi dès le départ ? Car j'ai mis pas mal de temps à écrire les scripts que j'utilise actuellement.

Je vais quand-même chercher s'il n'existe pas une astuce qui permettrait un fonctionnement acceptable de l'ensemble des scripts tel que je le souhaite, sans que ce soit trop une usine à gaz et même si ça ne respecte pas le contexte "multi-thread" normalement prévu pour ce type de situation.

Si je trouve quelque chose dans quelques jours, je proposerai une solution.

En attendant, encore merci pour ta contribution.

Krys006

[djibril]

Avec Win32::Process, tu peux parfaitement faire ce que tu veux.
Lit bien la documentation car il te permet d'obtenir pleins d'informations.

Moi, sans avoir à faire du multithread et company, je ferais ceci.

ton script 1 se lance. En début de script 1, tu génères un fichier qui contiendra le début (date) d'execution et la pid.

Ton script 2 se lance et lit ce fichier. S'il est présent => le script 1 tourne et tu compares les dates. si besoin, tu kill le process via l'information contenu dans le fichier. si le fichier n'existe plus. Tu considères qu'il est fini.

Ou mieux, tu ne fais qu'un seul programme qui lance le programme 1 via Win32::Process. Ainsi, tu auras toutes les informations possible (pid, date de début...).
Ensuite, tu te fais une boucle qui endort ton programme pendant 1 minute par exemple. Au bout de 60 boucles, si tu estimes que le programme 1 est trop long, tu le kill toujours via Win32::Process et roule ma poule.

Ce module est excellent et je l'utilise régulièrement lorsque je fais des interface Tk vu que le multithread n'y est pas natif. Il te permet de lancer des programmes externes dans un autre process et tu as donc la main dans ton programme.

Voilà !