pour info .... on a un bug que je n arrive pas a resoudre. cat << g - > renvoie 0 au lieu de 130

[faboussard]

est ce un pb de signal ? ( certainement) ou bien dexecution dans laquelle cat est executee avanle heredoc ( peu probable) ... mais bon nos signaux sont assez instables donc moi je laisserais comme ca, tant pis ..

A linverse si le heredoc est ouvert seul ( << g sans cat devant), la on obtient le bon code de sortie.

➜ minishell git:(check_malloc_parsing) ✗ ./minishell

Minishell>$ cat << g ^C Minishell>$ echo $? 0 Minishell>$ << g ^C Minishell>$ echo $? 130

[melobern]

Le heredoc est forcément exécuté avant cat (fait partie des infiles qui sont ouverts avant que l'execution soit lancée, donc pas de processus enfants exec tant que heredoc n'est pas fini), et je ne comprends pas comment cat pourrait être exécuté alors que le prompt est rendu. Le pire étant que cat tout seul avec une entrée standard coupée par C, ça donne aussi 130. Je vais voir si je trouve une solution, mais ça me parait bien étrange :eyes:

[faboussard]

daccord.

oui donc on dirait que les deux sannulent . super . (ironie).

[melobern]

C'est maintenant que j'ai éteint l'ordi que je pense à une explication possible, permettant une résolution potentielle. Donc avant d'oublier : Comment je pense que ça se passe : Le heredoc crée le fichier, lance son processus enfant. Son processus est interrompu, le processus enfant envoie 130. Mais comme le fichier existe et est vide, cat s'effectue bien dessus. Cat se fait sur le fichier vide, ce qui n'affiche rien : super 👍🏻 tout s'est bien passé, code 0 ! 🎉🎉🎉

Du coup il faudrait que j'arrive à capter si le heredoc s'est fini par 130, et si est le cas, que l'exec ne s'exécute pas de la même manière qu'il ne s'exécute pas si le fichier n'a pas pu être ouvert.

Je devrais peut-être rajouter un booléen du style heredoc_interrupted, et s'il est égal à 1, renvoyer 130.

[melobern]

Fixed :heavy_check_mark: (Juste pour le plaisir de fermer cette issue).