je voulais faire un simple fork, avec le fils executant un code externe ...
sous redhat j avais ecrit un petit code du style :
int pif = fork();
if (pid == 0) { // le fils
int ret execvp("le programme externe", 0);
// ici je regarde le code retour
}
...
Mon programme externe s'execute, va jusqu'a la fin, et mon code retour
est bon...
Les admin ont passes ma machine en centos4.0
maintenant, le programme externe s'execute toujours tres bien (j'ai
verifie qu'il s'execute jusqu'a la derniere ligne de code), par contre
le code retour est -1 (et errno = 10) !!!
Je peut supprimer le fork(), et remplacer tout par :
int ret = system("mon programme externe");
J'ai le meme probleme :(
quelqu'un aurait une idée sur un code retour qui me semblerait erroné ???
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
Pascal Bourguignon
ricky writes:
bonjour,
je voulais faire un simple fork, avec le fils executant un code externe ... sous redhat j avais ecrit un petit code du style :
int pif = fork(); if (pid == 0) { // le fils int ret execvp("le programme externe", 0); // ici je regarde le code retour
Non. Ici, tu peux regarder le résultat de execvp quand il n'arrive pas à lancer le programme externe, mais s'il y arrive, il ne retourne jamais.
} ...
Mon programme externe s'execute, va jusqu'a la fin, et mon code retour est bon...
Non, jamais.
Les admin ont passes ma machine en centos4.0
maintenant, le programme externe s'execute toujours tres bien (j'ai verifie qu'il s'execute jusqu'a la derniere ligne de code), par contre le code retour est -1 (et errno = 10) !!! Je peut supprimer le fork(), et remplacer tout par : int ret = system("mon programme externe"); J'ai le meme probleme :(
Non, avec system, tu as plein d'autres problèmes. Il vaut mieux éviter system(3) en général.
quelqu'un aurait une idée sur un code retour qui me semblerait erroné ???
Tu as une drôle de notion completement fantaisiste. Ça pourrait être bien de lire quelque tutoriel ou livre sur la programmation unix...
En résumé, il faut distinger le résultat d'une fonction ou appel système, du status retourné par un processus.
Les résultats sont retournés avec une instruction C return, et récoltés comme résultat de l'expression appelant la fonction ou appel système:
int execvp(...){ ... if(je_n_arrive_pas_a_executer_le_program){ errno=ESOMERROR; return(1); } }
int res=execvp(...);
Tandis que le status d'un processus est composé de deux valeurs, un code sur 8 bit indiquant si le status a été terminé normalement ou sur réception d'un signal non traité, et d'une valeur sur 8 bit donnée par le status via l'appel système _exit(2).
int pid=fork(); if(pid==0){ ... _exit(result); }else{ int status=wait(pid); if(WIFEXITED(status)){ int result=WEXITSTATUS(status); ... } ... }
"By filing this bug report you have challenged the honor of my family. Prepare to die!"
ricky <eric_AOTERnyme@yahoo.fr> writes:
bonjour,
je voulais faire un simple fork, avec le fils executant un code externe ...
sous redhat j avais ecrit un petit code du style :
int pif = fork();
if (pid == 0) { // le fils
int ret execvp("le programme externe", 0);
// ici je regarde le code retour
Non. Ici, tu peux regarder le résultat de execvp quand il n'arrive
pas à lancer le programme externe, mais s'il y arrive, il ne retourne
jamais.
}
...
Mon programme externe s'execute, va jusqu'a la fin, et mon code retour
est bon...
Non, jamais.
Les admin ont passes ma machine en centos4.0
maintenant, le programme externe s'execute toujours tres bien (j'ai
verifie qu'il s'execute jusqu'a la derniere ligne de code), par contre
le code retour est -1 (et errno = 10) !!!
Je peut supprimer le fork(), et remplacer tout par :
int ret = system("mon programme externe");
J'ai le meme probleme :(
Non, avec system, tu as plein d'autres problèmes. Il vaut mieux
éviter system(3) en général.
quelqu'un aurait une idée sur un code retour qui me semblerait erroné ???
Tu as une drôle de notion completement fantaisiste. Ça pourrait être
bien de lire quelque tutoriel ou livre sur la programmation unix...
En résumé, il faut distinger le résultat d'une fonction ou appel
système, du status retourné par un processus.
Les résultats sont retournés avec une instruction C return, et
récoltés comme résultat de l'expression appelant la fonction ou appel
système:
int execvp(...){
...
if(je_n_arrive_pas_a_executer_le_program){
errno=ESOMERROR;
return(1);
}
}
int res=execvp(...);
Tandis que le status d'un processus est composé de deux valeurs, un
code sur 8 bit indiquant si le status a été terminé normalement ou sur
réception d'un signal non traité, et d'une valeur sur 8 bit donnée par
le status via l'appel système _exit(2).
int pid=fork();
if(pid==0){
...
_exit(result);
}else{
int status=wait(pid);
if(WIFEXITED(status)){
int result=WEXITSTATUS(status);
...
}
...
}
je voulais faire un simple fork, avec le fils executant un code externe ... sous redhat j avais ecrit un petit code du style :
int pif = fork(); if (pid == 0) { // le fils int ret execvp("le programme externe", 0); // ici je regarde le code retour
Non. Ici, tu peux regarder le résultat de execvp quand il n'arrive pas à lancer le programme externe, mais s'il y arrive, il ne retourne jamais.
} ...
Mon programme externe s'execute, va jusqu'a la fin, et mon code retour est bon...
Non, jamais.
Les admin ont passes ma machine en centos4.0
maintenant, le programme externe s'execute toujours tres bien (j'ai verifie qu'il s'execute jusqu'a la derniere ligne de code), par contre le code retour est -1 (et errno = 10) !!! Je peut supprimer le fork(), et remplacer tout par : int ret = system("mon programme externe"); J'ai le meme probleme :(
Non, avec system, tu as plein d'autres problèmes. Il vaut mieux éviter system(3) en général.
quelqu'un aurait une idée sur un code retour qui me semblerait erroné ???
Tu as une drôle de notion completement fantaisiste. Ça pourrait être bien de lire quelque tutoriel ou livre sur la programmation unix...
En résumé, il faut distinger le résultat d'une fonction ou appel système, du status retourné par un processus.
Les résultats sont retournés avec une instruction C return, et récoltés comme résultat de l'expression appelant la fonction ou appel système:
int execvp(...){ ... if(je_n_arrive_pas_a_executer_le_program){ errno=ESOMERROR; return(1); } }
int res=execvp(...);
Tandis que le status d'un processus est composé de deux valeurs, un code sur 8 bit indiquant si le status a été terminé normalement ou sur réception d'un signal non traité, et d'une valeur sur 8 bit donnée par le status via l'appel système _exit(2).
int pid=fork(); if(pid==0){ ... _exit(result); }else{ int status=wait(pid); if(WIFEXITED(status)){ int result=WEXITSTATUS(status); ... } ... }
"By filing this bug report you have challenged the honor of my family. Prepare to die!"
ricky
bonjour
int pif = fork(); if (pid == 0) { // le fils int ret execvp("le programme externe", 0);
// ici je regarde le code retour
Non. Ici, tu peux regarder le résultat de execvp quand il n'arrive pas à lancer le programme externe, mais s'il y arrive, il ne retourne jamais.
ais je ecrit le contraire ? j'ai marque : "je regarde le code retour" ... s'il n'y a pas eu de retour , c'est que cela s'est bien passe et cette ligne ne sert a rien pour moi, sinon j'ai -1 ...
Mon programme externe s'execute, va jusqu'a la fin, et mon code retour est bon...
Non, jamais.
ais je ecrit que code retour bon impliquait une valeur ? alors je vais preciser : il n'y a pas de -1 ... ca te va mieux ???
maintenant, le programme externe s'execute toujours tres bien (j'ai verifie qu'il s'execute jusqu'a la derniere ligne de code), par contre le code retour est -1 (et errno = 10) !!! Je peut supprimer le fork(), et remplacer tout par : int ret = system("mon programme externe"); J'ai le meme probleme :(
Non, avec system, tu as plein d'autres problèmes. Il vaut mieux éviter system(3) en général.
bon oki mais cette reponse n'a rien a voir avec le probleme, qui se produit quelle que soit la methode d'appel, exec ou system...
avant cela fonctionnait, je voulais juste savoir en quoi un changement d'os de redhat a centos pouvait modifier completement le comportement au point de m'empecher d'avoir le bon resultat ..
Tu as une drôle de notion completement fantaisiste. Ça pourrait être bien de lire quelque tutoriel ou livre sur la programmation unix...
euh, et toi de lire un message sans l'interpreter a ta guise ... ca pourrait etre bien de ne pas condamner tout de suite ...
En résumé, il faut distinger le résultat d'une fonction ou appel système, du status retourné par un processus.
merci, j'en suis tout esbaudi :)
snip
ouije le sais , je n'ai jamais ecrit le contraire !!!
et pour preciser mon probleme, les deux (status du processus ET code retour) indiquent qu'il y a eu probleme, or tout s'est bien passé pour le code appelé... c'est ca mon problème ...
bonjour
int pif = fork();
if (pid == 0) { // le fils
int ret execvp("le programme externe", 0);
// ici je regarde le code retour
Non. Ici, tu peux regarder le résultat de execvp quand il n'arrive
pas à lancer le programme externe, mais s'il y arrive, il ne retourne
jamais.
ais je ecrit le contraire ?
j'ai marque : "je regarde le code retour" ... s'il n'y a pas eu de
retour , c'est que cela s'est bien passe et cette ligne ne sert a rien
pour moi, sinon j'ai -1 ...
Mon programme externe s'execute, va jusqu'a la fin, et mon code retour
est bon...
Non, jamais.
ais je ecrit que code retour bon impliquait une valeur ?
alors je vais preciser : il n'y a pas de -1 ... ca te va mieux ???
maintenant, le programme externe s'execute toujours tres bien (j'ai
verifie qu'il s'execute jusqu'a la derniere ligne de code), par contre
le code retour est -1 (et errno = 10) !!!
Je peut supprimer le fork(), et remplacer tout par :
int ret = system("mon programme externe");
J'ai le meme probleme :(
Non, avec system, tu as plein d'autres problèmes. Il vaut mieux
éviter system(3) en général.
bon oki mais cette reponse n'a rien a voir avec le probleme, qui se
produit quelle que soit la methode d'appel, exec ou system...
avant cela fonctionnait, je voulais juste savoir en quoi un changement
d'os de redhat a centos pouvait modifier completement le comportement au
point de m'empecher d'avoir le bon resultat ..
Tu as une drôle de notion completement fantaisiste. Ça pourrait être
bien de lire quelque tutoriel ou livre sur la programmation unix...
euh, et toi de lire un message sans l'interpreter a ta guise ... ca
pourrait etre bien de ne pas condamner tout de suite ...
En résumé, il faut distinger le résultat d'une fonction ou appel
système, du status retourné par un processus.
merci, j'en suis tout esbaudi :)
snip
ouije le sais , je n'ai jamais ecrit le contraire !!!
et pour preciser mon probleme, les deux (status du processus ET code
retour) indiquent qu'il y a eu probleme, or tout s'est bien passé pour
le code appelé...
c'est ca mon problème ...
int pif = fork(); if (pid == 0) { // le fils int ret execvp("le programme externe", 0);
// ici je regarde le code retour
Non. Ici, tu peux regarder le résultat de execvp quand il n'arrive pas à lancer le programme externe, mais s'il y arrive, il ne retourne jamais.
ais je ecrit le contraire ? j'ai marque : "je regarde le code retour" ... s'il n'y a pas eu de retour , c'est que cela s'est bien passe et cette ligne ne sert a rien pour moi, sinon j'ai -1 ...
Mon programme externe s'execute, va jusqu'a la fin, et mon code retour est bon...
Non, jamais.
ais je ecrit que code retour bon impliquait une valeur ? alors je vais preciser : il n'y a pas de -1 ... ca te va mieux ???
maintenant, le programme externe s'execute toujours tres bien (j'ai verifie qu'il s'execute jusqu'a la derniere ligne de code), par contre le code retour est -1 (et errno = 10) !!! Je peut supprimer le fork(), et remplacer tout par : int ret = system("mon programme externe"); J'ai le meme probleme :(
Non, avec system, tu as plein d'autres problèmes. Il vaut mieux éviter system(3) en général.
bon oki mais cette reponse n'a rien a voir avec le probleme, qui se produit quelle que soit la methode d'appel, exec ou system...
avant cela fonctionnait, je voulais juste savoir en quoi un changement d'os de redhat a centos pouvait modifier completement le comportement au point de m'empecher d'avoir le bon resultat ..
Tu as une drôle de notion completement fantaisiste. Ça pourrait être bien de lire quelque tutoriel ou livre sur la programmation unix...
euh, et toi de lire un message sans l'interpreter a ta guise ... ca pourrait etre bien de ne pas condamner tout de suite ...
En résumé, il faut distinger le résultat d'une fonction ou appel système, du status retourné par un processus.
merci, j'en suis tout esbaudi :)
snip
ouije le sais , je n'ai jamais ecrit le contraire !!!
et pour preciser mon probleme, les deux (status du processus ET code retour) indiquent qu'il y a eu probleme, or tout s'est bien passé pour le code appelé... c'est ca mon problème ...
root
bonjour,
je voulais faire un simple fork, avec le fils executant un code externe ... sous redhat j avais ecrit un petit code du style :
int pif = fork(); if (pid == 0) { // le fils int ret execvp("le programme externe", 0); // ici je regarde le code retour } ...
Mon programme externe s'execute, va jusqu'a la fin, et mon code retour est bon...
Les admin ont passes ma machine en centos4.0
maintenant, le programme externe s'execute toujours tres bien (j'ai verifie qu'il s'execute jusqu'a la derniere ligne de code), par contre le code retour est -1 (et errno = 10) !!!
C'est impossible que ton programme lancé par execvp se déroule correctement et que tu puisse par la suite consulter le code retour "ret". Il manque alors un morceau de code dans ton exemple et tu consultes le code retour dans le père et pas dans le fils ? car si le execvp est bien déroulé, alors tout le code suivant l'instruction exec du fils n'est jamais executé (c.f. man execvp).
Le errno correspond a une erreur "ECHILD No child process". Si tu observe cette erreur ECHILD dans le fils après avoir fait le execvp, c'est que ton programme externe n'est pas lancé.
Je peut supprimer le fork(), et remplacer tout par : int ret = system("mon programme externe"); J'ai le meme probleme :(
Comment est lancé ton programme C ? par cron ? est-il lancé sous un utilisateur particulier/different de celui avec lequel du developpe et teste le programme ? variable d'environnement qui ont changé au passage en centos4.0 (PATH, etc.), chemin d'accès a ton programme externe qui a changé, repertoire qui ne sont plus accessbles à cet utilisateur ? ton programme externe est un script dont l'interpreteur n'est pas installé/à changé de place ?
bonjour,
je voulais faire un simple fork, avec le fils executant un code externe ...
sous redhat j avais ecrit un petit code du style :
int pif = fork();
if (pid == 0) { // le fils
int ret execvp("le programme externe", 0);
// ici je regarde le code retour
}
...
Mon programme externe s'execute, va jusqu'a la fin, et mon code retour
est bon...
Les admin ont passes ma machine en centos4.0
maintenant, le programme externe s'execute toujours tres bien (j'ai
verifie qu'il s'execute jusqu'a la derniere ligne de code), par contre
le code retour est -1 (et errno = 10) !!!
C'est impossible que ton programme lancé par execvp se déroule
correctement et que tu puisse par la suite consulter le code retour "ret".
Il manque alors un morceau de code dans ton exemple et tu consultes le
code retour dans le père et pas dans le fils ? car si le execvp est bien
déroulé, alors tout le code suivant l'instruction exec du fils n'est
jamais executé (c.f. man execvp).
Le errno correspond a une erreur "ECHILD No child process". Si tu
observe cette erreur ECHILD dans le fils après avoir fait le execvp,
c'est que ton programme externe n'est pas lancé.
Je peut supprimer le fork(), et remplacer tout par :
int ret = system("mon programme externe");
J'ai le meme probleme :(
Comment est lancé ton programme C ? par cron ? est-il lancé sous un
utilisateur particulier/different de celui avec lequel du developpe et
teste le programme ? variable d'environnement qui ont changé au passage
en centos4.0 (PATH, etc.), chemin d'accès a ton programme externe qui a
changé, repertoire qui ne sont plus accessbles à cet utilisateur ? ton
programme externe est un script dont l'interpreteur n'est pas installé/à
changé de place ?
je voulais faire un simple fork, avec le fils executant un code externe ... sous redhat j avais ecrit un petit code du style :
int pif = fork(); if (pid == 0) { // le fils int ret execvp("le programme externe", 0); // ici je regarde le code retour } ...
Mon programme externe s'execute, va jusqu'a la fin, et mon code retour est bon...
Les admin ont passes ma machine en centos4.0
maintenant, le programme externe s'execute toujours tres bien (j'ai verifie qu'il s'execute jusqu'a la derniere ligne de code), par contre le code retour est -1 (et errno = 10) !!!
C'est impossible que ton programme lancé par execvp se déroule correctement et que tu puisse par la suite consulter le code retour "ret". Il manque alors un morceau de code dans ton exemple et tu consultes le code retour dans le père et pas dans le fils ? car si le execvp est bien déroulé, alors tout le code suivant l'instruction exec du fils n'est jamais executé (c.f. man execvp).
Le errno correspond a une erreur "ECHILD No child process". Si tu observe cette erreur ECHILD dans le fils après avoir fait le execvp, c'est que ton programme externe n'est pas lancé.
Je peut supprimer le fork(), et remplacer tout par : int ret = system("mon programme externe"); J'ai le meme probleme :(
Comment est lancé ton programme C ? par cron ? est-il lancé sous un utilisateur particulier/different de celui avec lequel du developpe et teste le programme ? variable d'environnement qui ont changé au passage en centos4.0 (PATH, etc.), chemin d'accès a ton programme externe qui a changé, repertoire qui ne sont plus accessbles à cet utilisateur ? ton programme externe est un script dont l'interpreteur n'est pas installé/à changé de place ?
ricky
bonjour
C'est impossible que ton programme lancé par execvp se déroule correctement et que tu puisse par la suite consulter le code retour "ret".
je confirme, en fait, je me suis mal exprime !
j'ai un test sur le code retour, et si tout se passe bien, evidement ce test n est jamais execute... et dans le pere, j'ai un second test histoire de voir ce qui se passe
Il manque alors un morceau de code dans ton exemple et tu consultes le code retour dans le père et pas dans le fils ? car si le execvp est bien déroulé, alors tout le code suivant l'instruction exec du fils n'est jamais executé (c.f. man execvp).
oui tout a fait ! j'ai un test du errno dans le pere, qui reste toujours a 10 que je lance n'importe quoi en fait
Jusqu'a la centos, je n'ai jamais eu de probleme avec ce code...
Le errno correspond a une erreur "ECHILD No child process".
oui tout a fait Cela correspond aussi a une erreur SGNCHLD = SGN_IGN et aussi au cas ou le fils teste n'appartient plus au pere. Mais ces deux cas ne semblent pas correspondre non plus .
Si tu
observe cette erreur ECHILD dans le fils après avoir fait le execvp, c'est que ton programme externe n'est pas lancé.
non je confirme, errno est teste dans le pere, j'ai ete imprecis.
Mon programme a bien ecrit les fichiers qu'il est cense fournir, c'est la mon probleme ! et j'ai mon errno malgre tout .. Donc en fait, ce qui m ennuie, c'est que je ne peux pluis differencier le cas ou mon programme a echoue de celui ou il a fonctionne
j'ai essaye un waitpid du fils, et le waitpid renvoie lui aussi les memes codes
Comment est lancé ton programme C ? par cron ?
non a la main
est-il lancé sous un
utilisateur particulier/different de celui avec lequel du developpe et teste le programme ? variable d'environnement qui ont changé au passage en centos4.0 (PATH, etc.), chemin d'accès a ton programme externe qui a changé, repertoire qui ne sont plus accessbles à cet utilisateur ? ton programme externe est un script dont l'interpreteur n'est pas installé/à changé de place ?
j ai essaye de verifier tout ca, sans grand succes ! le plus "amusant" est que si je lance "gvd toto" a la place de "toto" (gvd = l'interface du debugger), tout marche super bien, le debugger ne remarque rien d'anormal et moi j'ai bien mon test du cote du pere qui donne les bons resultats comme avant ... donc je ne peux pas le debugger en utilisant ce moyen !
bonjour
C'est impossible que ton programme lancé par execvp se déroule
correctement et que tu puisse par la suite consulter le code retour "ret".
je confirme, en fait, je me suis mal exprime !
j'ai un test sur le code retour, et si tout se passe bien, evidement ce
test n est jamais execute...
et dans le pere, j'ai un second test histoire de voir ce qui se passe
Il manque alors un morceau de code dans ton exemple et tu consultes le
code retour dans le père et pas dans le fils ? car si le execvp est bien
déroulé, alors tout le code suivant l'instruction exec du fils n'est
jamais executé (c.f. man execvp).
oui tout a fait !
j'ai un test du errno dans le pere, qui reste toujours a 10 que je lance
n'importe quoi en fait
Jusqu'a la centos, je n'ai jamais eu de probleme avec ce code...
Le errno correspond a une erreur "ECHILD No child process".
oui tout a fait
Cela correspond aussi a une erreur SGNCHLD = SGN_IGN et aussi au cas ou
le fils teste n'appartient plus au pere. Mais ces deux cas ne semblent
pas correspondre non plus .
Si tu
observe cette erreur ECHILD dans le fils après avoir fait le execvp,
c'est que ton programme externe n'est pas lancé.
non je confirme, errno est teste dans le pere, j'ai ete imprecis.
Mon programme a bien ecrit les fichiers qu'il est cense fournir, c'est
la mon probleme ! et j'ai mon errno malgre tout ..
Donc en fait, ce qui m ennuie, c'est que je ne peux pluis differencier
le cas ou mon programme a echoue de celui ou il a fonctionne
j'ai essaye un waitpid du fils, et le waitpid renvoie lui aussi les
memes codes
Comment est lancé ton programme C ? par cron ?
non a la main
est-il lancé sous un
utilisateur particulier/different de celui avec lequel du developpe et
teste le programme ? variable d'environnement qui ont changé au passage
en centos4.0 (PATH, etc.), chemin d'accès a ton programme externe qui a
changé, repertoire qui ne sont plus accessbles à cet utilisateur ? ton
programme externe est un script dont l'interpreteur n'est pas installé/à
changé de place ?
j ai essaye de verifier tout ca, sans grand succes !
le plus "amusant" est que si je lance "gvd toto" a la place de "toto"
(gvd = l'interface du debugger), tout marche super bien, le debugger ne
remarque rien d'anormal et moi j'ai bien mon test du cote du pere qui
donne les bons resultats comme avant ... donc je ne peux pas le
debugger en utilisant ce moyen !
C'est impossible que ton programme lancé par execvp se déroule correctement et que tu puisse par la suite consulter le code retour "ret".
je confirme, en fait, je me suis mal exprime !
j'ai un test sur le code retour, et si tout se passe bien, evidement ce test n est jamais execute... et dans le pere, j'ai un second test histoire de voir ce qui se passe
Il manque alors un morceau de code dans ton exemple et tu consultes le code retour dans le père et pas dans le fils ? car si le execvp est bien déroulé, alors tout le code suivant l'instruction exec du fils n'est jamais executé (c.f. man execvp).
oui tout a fait ! j'ai un test du errno dans le pere, qui reste toujours a 10 que je lance n'importe quoi en fait
Jusqu'a la centos, je n'ai jamais eu de probleme avec ce code...
Le errno correspond a une erreur "ECHILD No child process".
oui tout a fait Cela correspond aussi a une erreur SGNCHLD = SGN_IGN et aussi au cas ou le fils teste n'appartient plus au pere. Mais ces deux cas ne semblent pas correspondre non plus .
Si tu
observe cette erreur ECHILD dans le fils après avoir fait le execvp, c'est que ton programme externe n'est pas lancé.
non je confirme, errno est teste dans le pere, j'ai ete imprecis.
Mon programme a bien ecrit les fichiers qu'il est cense fournir, c'est la mon probleme ! et j'ai mon errno malgre tout .. Donc en fait, ce qui m ennuie, c'est que je ne peux pluis differencier le cas ou mon programme a echoue de celui ou il a fonctionne
j'ai essaye un waitpid du fils, et le waitpid renvoie lui aussi les memes codes
Comment est lancé ton programme C ? par cron ?
non a la main
est-il lancé sous un
utilisateur particulier/different de celui avec lequel du developpe et teste le programme ? variable d'environnement qui ont changé au passage en centos4.0 (PATH, etc.), chemin d'accès a ton programme externe qui a changé, repertoire qui ne sont plus accessbles à cet utilisateur ? ton programme externe est un script dont l'interpreteur n'est pas installé/à changé de place ?
j ai essaye de verifier tout ca, sans grand succes ! le plus "amusant" est que si je lance "gvd toto" a la place de "toto" (gvd = l'interface du debugger), tout marche super bien, le debugger ne remarque rien d'anormal et moi j'ai bien mon test du cote du pere qui donne les bons resultats comme avant ... donc je ne peux pas le debugger en utilisant ce moyen !
