Thanks to everyone here... I am slowly able to realize the shell... I'm actually stuck at piping... I am able to handle a single pipe but how do I solve the problem of multiple pipes? I know it can be solved using recursion but some pseudo algorithm will be excellent... I don't understand how to actually use recursion here... I'm currently doing something like a parent creates two children and the first one executes one command and pipes it onto the second child which displays the output...
And when I used valgrind, to my surprise I found 15 memory leaks from the piping function that I wrote and I don't understand what could've gone wrong... My pseudo code looks something like this:
Code:
int fd[2]; /* provide file descriptor pointer array for pipe */
pid_t pid1, pid2; /* process ids for each child */
/* create pipe and check for an error */
/* apply fork and check for error */
/* processing for child */
close (fd[1]); /* close output end, leaving input open */
/* set standard input to pipe */
if (fd[0] != STDIN_FILENO)
{
if (dup2(fd[0], STDIN_FILENO) != STDIN_FILENO)
{
perror("dup2 error for standard input");
exit(1);
}
close(fd[0]);
}
execlp the second function
//First child finished
else
{
/* processing for parent */
/* spawn second process */
/* apply fork again for second child*/
/* processing for child */
close (fd[0]);
/* set standard output to pipe */
if (fd[1] != STDOUT_FILENO)
{
if (dup2(fd[1], STDOUT_FILENO) != STDOUT_FILENO)
{
perror("dup2 error for standard output");
exit(1);
}
close(fd[1]); /* not needed after dup2 */
}
execlp the first function
/* print to the pipe, now standard output */
}
else
{
/* processing continues for parent */
close(fd[0]);
close(fd[1]);
waitpid (pid1, NULL, 0); /* wait for first child to finish */
waitpid (pid2, NULL, 0); /* wait for second child to finish */
}
}
Am I doing something wrong?
Last edited by Legend986; 10-24-2007 at 02:45 AM..
if somebody can help me pls.
i need the source code for a shell which compiles C or java programs.
i need a very short and simple one, just for the compiling part, in UNIX
Respect (4 Replies)
#!/usr/bin/m4
when running m4 scripts with "#!/usr/bin/m4" they are executed properly, but "#!/usr/bin/m4" is printed out - how to avoid it?
Thanks in advance. (5 Replies)
Hello guys - do you have any sample program implementing UNIX commands in an interpreter with Java? I can look up the simple ones such "ls" etc and then write my own commands.
I would appreciate it. (2 Replies)
Hi,
I am writing a shell script that connects to a remote server and performs some tasks on the server and exits.
Since i am using a ssh connection, i am using a "expect" utility to supply the password automatically (which is present within the script).
In order to use this utility, i need to... (3 Replies)
Hi. My name is Caleb (a.k.a RagingNinja) form the whited00r forums. (Whited00r makes custom firmware for iOS devices).
I have been learning and creating simple shells scripts. I have been recently using VIM for Windows or using VirtualBox to run the UBUNTU OS within VirtualBox to create my shell... (2 Replies)
Hi,
Is it possible to choose the inerpreter conditionally.
For example, if whereis bash returns /usr/bin/bash then i need to choose #!/usr/bin/bash
else i need to use #!/usr/bin/sh.
Is it possible to achieve in a shell script?
Thanks (1 Reply)
Discussion started by: pandeesh
1 Replies
LEARN ABOUT MINIX
close
CLOSE(2) System Calls Manual CLOSE(2)NAME
close - delete a descriptor
SYNOPSIS
#include <unistd.h>
int close(int d)
DESCRIPTION
The close call deletes a descriptor from the per-process object reference table. If this is the last reference to the underlying object,
then it will be deactivated. For example, on the last close of a file the current seek pointer associated with the file is lost; on the
last close of a TCP/IP descriptor associated naming information and queued data are discarded; on the last close of a file holding an advi-
sory lock the lock is released (see further fcntl(2)).
A close of all of a process's descriptors is automatic on exit, but since there is a limit on the number of active descriptors per process,
close is necessary for programs that deal with many descriptors.
When a process forks (see fork(2)), all descriptors for the new child process reference the same objects as they did in the parent before
the fork. If a new process is then to be run using execve(2), the process would normally inherit these descriptors. Most of the descrip-
tors can be rearranged with dup2(2) or deleted with close before the execve is attempted, but if some of these descriptors will still be
needed if the execve fails, it is necessary to arrange for them to be closed if the execve succeeds. For this reason, the call ``fcntl(d,
F_SETFD, flags)'' is provided, that can be used to mark a descriptor "close on exec" by setting the FD_CLOEXEC flag:
fcntl(d, F_SETFD, fcntl(d, F_GETFD) | FD_CLOEXEC);
RETURN VALUE
Upon successful completion, a value of 0 is returned. Otherwise, a value of -1 is returned and the global integer variable errno is set to
indicate the error.
ERRORS
Close will fail if:
[EBADF] D is not an active descriptor.
SEE ALSO open(2), pipe(2), execve(2), fcntl(2).
4th Berkeley Distribution May 22, 1986 CLOSE(2)