idem, dans l'autre sens, pour "sort", l'entrée standard et tube[0]

Par ailleurs, c'est plutôt une bonne idée de fermer les descripteurs dont on n'a plus besoin. Après tout, il n'y en a qu'un nombre limité. C'est comme pour un fichier : quand tu as finit de le lire, ou quand tu n'as plus rien à y écrire, tu le fermes.

Ok faut que je regarde toute cette histoire de blocage alors

Dernière petite question : dans tous les cours "propres" que j'ai pu voir, il y a ces lignes :

close(tube[0]);
dup2(tube[1],1);
close(tube[1]);

La première, aucun souci on ferme le coté du tube qu'on utilise pas dans le processus.
La deuxième no souci non plus, on connecte les flux.
Mais la troisième : pourquoi ferme t'on le descripteur crée via un pipe si on doit l'utiliser par la suite?Ici, on connecte l'entrée du tube a la sortie standard mais pourquoi ferme t-on l'entrée du tube juste après?

Merci encore.

Pourquoi les printf("coucou"); ne s'exécutent pas?

Les printf s’exécutent, mais la sortie standard est bufferisée. Le buffer est vidé à chaque retour chariot ou quand on lui demande explicitement (en ajoutant  fflush (stdout); après chaque printf) ou en faisant une lecture sur l'entrée standard. Dans ton cas, les 3 conditions sont fausses et manifestement (je l'ignorais ) le execl repart d'un buffer vide pour sa sortie standard.

Tout dépend de la façon dont le père attend la lecture. En général une lecture sur l'entrée standard est bloquante : le process attend tant qu'il n'y a rien à lire. Mais on peut aussi le programmer de façon à ce qu'il n'attende pas et il mourra si son fils n'est pas assez rapide à lui écrire.

Dans ton cas, le fils exécute "sort" qui reste bloquant en attendant qu'il arrive quelque chose sur son entrée standard et le père exécute "ls" qui envoie des données sur sa sortie standard donc sur l'entrée standard de son fils, puis meurt. Le fils cesse d'être bloqué par son entrée standard quand le pipe est rompu par la mort du père (à la fin de l'exéution du "ls"), fait alors le tri, affiche le résultat et meurt.

Donc non.:P

Donc oui , sauf si on définit explicitement le descripteur comme non bloquant.

voici mon code : il s'agit simplement de faire communiquer un processus père avec un processus fils

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
void pipe_shell(char* argv1, char* argv2);

int main(int argc,char* argv[])
{
        if(argc!=3)
                 exit(-1);

	pipe_shell(argv[1],argv[2]);
		
	return EXIT_SUCCESS;
}

void pipe_shell(char* argv1, char* argv2)
{
	int tube[2];
	pipe(tube);
	pid_t result_fork=fork();

	switch(result_fork)
	{
		case -1 : printf("Erreur creation processus\n");
			exit(-1);

		case 0 : /*processus fils*/
                        printf("coucou");
			close(tube[1]);
			dup2(tube[0],0);
			close(tube[0]);
			execl("/usr/bin/sort","sort",NULL);
			break;

		default : /*processus pere*/
			printf("coucou");
			close(tube[0]);
			dup2(tube[1],1);
			close(tube[1]);
			execl("/bin/ls","ls",NULL);

	}
}

Pourquoi les printf("coucou"); ne s'exécutent pas?

De plus si j'ai bien compris les processus sont tués dès que leurs instructions sont terminés mais admettons que le fils doit envoyer un message au père via un pipe; Admettons que ce soit au père de s'exécuter en premier il va terminer ses instructions, voyant qu'il n'y a rien à lire pour le moment et ne pourra pas lire ce que le fils lui envoie puis va mourir? mais dans la réalité les deux arrivent à communiquer donc quand un processus meurt-il réellement?Tourne t-il en boucle plusieurs fois de suite?Ou lors de l'accès en lecture d'un descripteur va t-il se mettre en pause jusqu'a ce qu'une donnée apparaisse?

Merci !