au moment de l'exec par le fils, il "exec" le shell lui même (argv[0]) au lieu du programme entré.
exit(0) après le wait ne devrait pas être là.
les modifications sur stdin/stdout doivent se faire dans le fils (avant l'exec). Là tu le fais dans le père/shell et, en plus, après le fork, ce qui n'a aucune incidence sur le fils, ce n'est certainement pas ce que tu veux..
surcharger l'argv du main pour construire ton argv pour l'execv est, en plus d'être carrément dégueulasse et illisible, dangereux car rien ne t'indique qu'il est bien dimensionné. Construis en un autre à l'aide de malloc! (btw fgets ne devrait pas non plus être utilisé, je l'avais déja dit à ton collègue ou à toi.
conseil: continue de découper ton code en fonctions, par exemple en faire une pour le fork+exec+modification stdou/stdin serait déja pas mal, voire une autre pour construire l'argv ou encore pour "parser" la ligne d'entrée
conseil: utilise "strace -o /tmp/trace -f -t ./shell" afin de savoir quels syscalls sont effectués par ton programme. L'argument "-f" est important, il demande de tracer aussi les fils. Avec le code posté, tu obtiens qq chose du genre (j'ai retirés les lignes non pertinentes).
La première ligne indique le pid. On voit bien que le wait fonctionne bien, mais que le fils (pid 3063) fait une lecture sur stdin (fd=0) et ne quitte qu'au moment on on entre CTRL+D (read=0 => EOF). Note que le fork est en fait le "clone", c'est la primitive noyau ("syscall") que la fonction fork de la libc utilise. Tu peux aussi utiliser ltrace (avec un L pour librairies), qui normalement te donne les noms de fonctions appellées, mais en règle générale, c'est beaucoup plus lent et verbeux, et il faut avoir les infos de débuggages.
# Quelques problèmes
Posté par benja . En réponse au message introduire redirection dans un minishell. Évalué à 2.
au moment de l'exec par le fils, il "exec" le shell lui même (argv[0]) au lieu du programme entré.
exit(0) après le wait ne devrait pas être là.
les modifications sur stdin/stdout doivent se faire dans le fils (avant l'exec). Là tu le fais dans le père/shell et, en plus, après le fork, ce qui n'a aucune incidence sur le fils, ce n'est certainement pas ce que tu veux..
surcharger l'argv du main pour construire ton argv pour l'execv est, en plus d'être carrément dégueulasse et illisible, dangereux car rien ne t'indique qu'il est bien dimensionné. Construis en un autre à l'aide de malloc! (btw fgets ne devrait pas non plus être utilisé, je l'avais déja dit à ton collègue ou à toi.
conseil: continue de découper ton code en fonctions, par exemple en faire une pour le fork+exec+modification stdou/stdin serait déja pas mal, voire une autre pour construire l'argv ou encore pour "parser" la ligne d'entrée
conseil: utilise "strace -o /tmp/trace -f -t ./shell" afin de savoir quels syscalls sont effectués par ton programme. L'argument "-f" est important, il demande de tracer aussi les fils. Avec le code posté, tu obtiens qq chose du genre (j'ai retirés les lignes non pertinentes).
La première ligne indique le pid. On voit bien que le wait fonctionne bien, mais que le fils (pid 3063) fait une lecture sur stdin (fd=0) et ne quitte qu'au moment on on entre CTRL+D (read=0 => EOF). Note que le fork est en fait le "clone", c'est la primitive noyau ("syscall") que la fonction fork de la libc utilise. Tu peux aussi utiliser ltrace (avec un L pour librairies), qui normalement te donne les noms de fonctions appellées, mais en règle générale, c'est beaucoup plus lent et verbeux, et il faut avoir les infos de débuggages.