#include<stdio.h>
#include<unistd.h>
#include<stdlib.h>
int main(int argc,char **argv)
{
int fd[2];
pid_t childpid;
pipe(fd);
childpid=fork();
if (childpid == -1)
{
perror("Error forking...");
exit(1);
}
if (childpid) /*parent proces*/ //grep .c
{
wait(&childpid); //waits till the child send output to pipe
close(fd[1]);
close(0); //stdin closed
dup2(fd[0],0);
execlp(argv[2],argv[2],argv[3],NULL);
}
if (childpid==0) //ls
{
close(fd[0]); /*Closes read side of pipe*/
close(1); //STDOUT closed
dup2(fd[1],1);
execl(argv[1],NULL);
}
return 0;
}
Se fornisco l'argomento della riga di comando come "ls grep .c", dovrei ottenere tutti i file ".c" visualizzati.Implementare le tubazioni ("|") utilizzando C .. (fork utilizzato)
Pseudocodice: - mio processo figlio verrà eseguito "ls" & processo padre verrà eseguito "grep .c" .. processo genitore aspetta finché il processo figlio viene completata in modo che bambino scrive al tubo. run
prova: -
bash-3.1$ ls | grep .c
1.c
hello.c
bash-3.1$ ./a.out ls grep .c
bash-3.1$
Perché che succede?
Ok. Ho ricevuto la risposta da solo. Ho usato "execl()" nel processo figlio che non cerca il nomefile usando la variabile d'ambiente $ PATH .... Se cambio in execlp(), il programma funziona come previsto. –
Probabilmente anche tu non vuoi "wait (& childpid);" (o il suo commento inaccurato) lì. Non attende che i dati arrivino dal bambino, attende fino a quando lo stato del processo secondario cambia - ad es. Uscita. Se il processo figlio scrive più di una pipe di dati (forse 8k), si bloccherà in attesa che il genitore legga, mentre il genitore attende ancora che esca. – jmb
quindi, cosa dovrei fare in modo che il genitore venga eseguito dopo che il bambino ha eseguito ...? –