Programming

Why should'nt builtins work in the middle of the pipe?

In my home directory,
I tried ls | set | grep path
O/P given was:

path (/usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /usr/games)


so what I'm basically asking is, if a builtin command occurs in the middle of a pipe sequence, is it executed in the parent shell process or as a subprocess?

In case it is executed in parent process, then we have the tedious task of closing the appropriate FDs before executing the next command, as the code never reaches ,
say case 0 : of your eg. statement.
the code for that would look like so:

Code:

for( all piped commands)
{
if (builtin)
{
execute the builtin command code here
close appropriate pipe ends to accomodate code for external commands
}
else
{
if(c->next !=NULL)
        {
            if(pipe(fd_pipe)<0)
            {
                perror("pipe");
            }
        }

        switch(pid= fork())
        {
        case -1 :
            perror("fork");
            break;
        default:
            //Close parent's copy of the write end of the pipe
            if(fd_pipe[1]>=0) close(fd_pipe[1]);

            //Store the intermediate read end which will
            //be used as read end for next process in the pipe
            //Close it for the last command as there is no one to read after it.
            if(intermed_desc >=0) close(intermed_desc);
            intermed_desc = fd_pipe[0];

            //Throw away pipe
            fd_pipe[0] = -1;
            fd_pipe[1]= -1;
            break;
        case 0 :
            // Map the intermediate read end stored to STDIN
            if(intermed_desc>=0)
            {
                if(dup2(intermed_desc, STDIN_FILENO)<0)
                {
                    perror("dup2");
                }
                close(intermed_desc);
            }
            //Map write end of pipe to STDOUT
            if(fd_pipe[1]>=0)
            {
                if(dup2(fd_pipe[1], STDOUT_FILENO)<0)
                {
                    perror("dup2");
                }
                close(fd_pipe[1]);
                close(fd_pipe[0]);
            }

                resolv_path(c,portion);
                if(execv(portion,c->args)<0)
                {
                    perror("execv");
                }

}
}

In case we execute the external version directly, then we needn't worry about closing the pipe ends correctly, as the builtin would be exec'ed like a normal external command.

In short .

First, there's generally no point to doing so -- set doesn't read from standard input.

There's constructs that can:

Code:

grep filename | while read LINE
do
        echo "$LINE"
done

...but there's two problems:

1) csh can't do this. Just one of its many design flaws.
2) The Bourne shell can, but it must launch a subshell to do so. It's run in a shell, but not your shell. (As a side-effect, LINE doesn't get set in the rest of the program, just inside the while-loop.)

I already hinted at why it needs to do this...

Imagine a shell where all of those are builtins, running inside the same shell process. How does it decide which gets to go when? If you tried read when the pipe was empty it'd freeze, you'd never have a chance to run grep.

You could set everything nonblocking and just poll, running each thing a bit at a time. It'd never freeze, but your program would consume 100% CPU even sitting there waiting for sleep.

You could cheat and just run them in order, saving to temp file, waiting for one to finish before sending the file into the next one. I think this is how DOS pretended to have rudimentary pipes even though it didn't have processes at all.

Or you could use buffers and logic and mutual exclusion between things to decide which gets to run when and prevent one part of the program from waiting forever for the other... Except there's already a system on your computer which does that -- the operating system.

Instead of reinventing the wheel, they fork() off another process to run a specific piece of script-within-a-script independently of the rest. When it waits for input, it's not freezing the entire program. Basically -- the shell fork()'s to run it. But since it's pure shell code, it doesn't exec() anything, the child process is used to run a subsection of shell code.

Again, compounded by the problem that csh is bad at this.

Good news everyone!
I got my shell to work in almost all cases. There are one or two bugs which I need to iron out, which I'll have a crack at tonight. Thank you for all your inputs!