Interactive shell stop pipe - c

Question

My program is as follow:
//... init fd[2] as pipe ...
if (child==0){
close(fd[1]);
dup2(fd[0], 0);
execlp("/bin/sh","sh",NULL);
} else {
close(fd[0]);
char *line; int nbytes=100; int bytes=0;
line=(char*) malloc(nbytes+1);
while ( (bytes = getline((char **)&line,&nbytes,stdin))!= -1 ){
write(fd[1],line, bytes);
}
}
This run OK, however when I try to replace exec("/bin/sh","sh",NULL) with exec("/bin/sh","sh","-i",NULL) to force an interactive shell, my program stop after executing the first command.
I'm new to pipe so please help me understand the reason and make interactive shell work... I also feel that my code to read line and pass to the child pipe is a bit odd.. is there any better way to achieve the same behavior ?

Answer 1

You should close(fd[0]); after the dup2() in the child. If you supply an absolute or relative path like "/bin/sh", there's no point in using execlp(); it will only do a PATH-based search for a bare filename (program name). The cast in the call to getline() should be unnecessary; avoid such casts whenever possible. You should include at least exit(1); after execlp() just in case it fails; a diagnostic message would be a good idea too. You should close(fd[1]); after the loop in the parent to indicate EOF to the child. (Just for once, it doesn't matter if you don't detect the error return from malloc(); it is legitimate to pass the address of a pointer where the pointer holds NULL to the getline() function, and it will then try to allocate memory itself. Of course, if the main program fails to allocate memory, it is highly likely that getline() will also fail to allocate memory.)
Those changes lead to:
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
int main(void)
{
int fd[2];
pid_t child;
if (pipe(fd) != 0)
perror("pipe");
else if ((child = fork()) < 0)
perror("fork");
else if (child == 0)
{
close(fd[1]);
dup2(fd[0], 0);
close(fd[0]);
execl("/bin/sh", "sh", NULL);
perror("oops");
exit(1);
}
else
{
close(fd[0]);
size_t nbytes = 100;
int bytes = 0;
char *line = (char*)malloc(nbytes+1);
while ((bytes = getline(&line, &nbytes, stdin)) != -1)
{
write(fd[1], line, bytes);
}
close(fd[1]);
}
return(0);
}
This compiles without complaint under stringent compilation flags:
gcc -O3 -g -std=c99 -Wall -Wextra xf.c -o xf
When run (on Mac OS X 10.7.3) with the code above (invoking sh without the -i option), things behave reasonably sanely. You can type commands and the shell executes them. You can type 'exit' and the shell exits, but the program you wrote (which I called xf) doesn't exit until I type a new command. It then exits because of a SIGPIPE signal as it writes to the now readerless pipe. There is no prompt from this shell because its standard input is not a terminal (it is a pipe).
When the sub-shell is run with the -i option, then there seems to be a fight between the job control shells about which shell is in charge of the terminal. When I run it, I get:
$ ps -f
UID PID PPID C STIME TTY TIME CMD
503 381 372 0 Wed08PM ttys001 0:00.07 -sh
503 21908 381 0 9:32PM ttys001 0:00.01 sh
$ ./xf
sh-3.2$
[1]+ Stopped(SIGTTIN) ./xf
$
$ ps -f
UID PID PPID C STIME TTY TIME CMD
503 381 372 0 Wed08PM ttys001 0:00.07 -sh
503 21908 381 0 9:32PM ttys001 0:00.01 sh
503 22000 21908 0 9:36PM ttys001 0:00.00 ./xf
503 22001 22000 0 9:36PM ttys001 0:00.00 sh -i
$ ls
awk.data osfile-keep.c pthread-2.c send.c xf
const-stuff.c perl.data pthread-3.c so.8854855.sql xf.c
fifocircle.c piped-merge-sort.c quine.c strandsort.c xf.dSYM
madump.c powa.c recv.c unwrap.c xxx.sql
makefile pthread-1.c regress.c vap.c yyy.sql
$ jobs
[1]+ Stopped(SIGTTIN) ./xf
$ fg %1
./xf
exit
$
(The initial -sh is the login shell for my terminal window. In that, I've run sh to get a sub-shell, and I've set the prompt PS1='$ ' to make the prompt distinctive.)
AFAICT, the sh-3.2$ prompt comes from the sh -i shell. The parent shell seems to be reading input, and has dumped the xf program into the background, which is not very civilized of it. The ps -f output doesn't show the ps command, which is a nuisance. I did manage to get the ls command to show up in a ps listing in one run, and it was the child of the original shell, not the sh -i run by xf. When I bring xf into the foreground, it immediately exits (presumably it reads 0 bytes from standard input, which indicates EOF, and so getline() returns -1, and everything shuts up shop. The exit is from the sh -i; it echoes it. It never got any input because the sh shell took command instead of letting xf have control of the terminal. That's pretty excruciatingly messy. I'm not sure why it happens like that, but it feels to me like it shouldn't happen like that.