Discussion :

[Padawan63400]

Bonjour,

Je constate actuellement que l'utilisation du exec() est differente sur un systeme Unix d'un systeme Windows.

Dans la definition, exec remplace le processus pere par le processus fils, chose respectee sous UNIX. Par contre, sur Windows, sous une fenetre d'invite de commandes dos, au moment du exec(), la fenetre rend l'invite de commande... alors que le nouveau processus n'est pas termine. De plus ce nouveau processus n'a pas remplace le precedent (pid different).

Je voulais savoir si d'autres personnes avaient deja rencontrees ce probleme.
A savoir que le probleme est le meme avec un programme en langage C++. Ce qui me laisse penser que l'interpretation d'un exec sous windows est erronee.

Si d'autres personnes ont deja rencontrees le probleme, et ont une solution pour le contourner (utilisation d'une API, etc).

Merci d'avance,

++

[d-jo]

Bonjour,
La réponse est simple : Windows ne gère pas les processus comme Unix.

Sous unix le processus fils est attaché au processus père (Typiquement, tu n'as pas la main sur la console avant la fin du processus fils). Sous Windows les processus ne sont (en gros) attachés qu'au processus qui en fait la demande (notion de handle).

ça c'est la théorie.

La fonction exec 'ne retourne pas' -

The exec function executes a system command and never returns

Elle lance un processus.

http://search.cpan.org/~rgarcia/perl...Perl_Functions


Donc si tu attend un _retour_ (même une fin) peut-être vaut-il mieux utiliser system

Joris

[Jedai]

Non, je pense que quand Padawan parle de retour il pense au fait que normalement, si un script appelé sur la ligne de commande utilise exec(), l'invite de commande ne doit pas revenir avant que la commande lancé par exec() ait fini.

Mais sous Windows, il n'est pas possible de faire un "vrai" exec(), Windows gère les processus différemment, en particulier on ne peut pas changer le code exécuté par un processus. Sous Unix toute la création de processus est fondé sur le couple fork()/exec(), mais Windows ne fonctionne pas du tout comme ça. Par conséquence les émulations de exec() ou de fork() sous Windows n'ont pas un comportement très unixiens, désolé. On ne peut pas y faire grand chose.

--
Jedaï

[d-jo]

Non, je pense que quand Padawan parle de retour il pense au fait que normalement, si un script appelé sur la ligne de commande utilise exec(), l'invite de commande ne doit pas revenir avant que la commande lancé par exec() ait fini.

Peut-être ce que j'ai dis semble confus.

En utilisant system au lieu d'exec, sous windows, on obtiens le même comportement qu'un exec sous unix.

Sous windows :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
exec 'notepad.exe'

Rends la main tout de suite

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
system 'notepad.exe'

Rends la main quand le bloc note est fermé.

Joris

[Jedai]

Ok, si tu voulais dire cela, nous sommes d'accord, cependant ce n'est pas le même comportement, en dehors du fait que sémantiquement , il faut rajouter un exit() après le system() pour obtenir un comportement proche de exec(), en pratique le system() n'a à peu près aucun des avantages de exec(), puisque le processus père continue à exister et à prendre de la place.

Néanmoins si le seul ennui est effectivement le comportement en console il va de soi que system() n'a pas ce problème puisque le processus père (qui a sa console) continue à être exécuté.

--
Jedaï