next up previous
Next: Material to be Submitted Up: No Title Previous: Problem Statement

Implementation Details

  1. In general, the execution of any of the programs above will be carried out by specifying the executable program name followed by the command line arguments. For example, the values A, and B must be command line arguments. Note that this is not the case for the mini-shell, in which the user must interactively type in the commands to the prompt that the mini-shell provides.
  2. See the man pages for more details about specific system or library calls and commands: fork(2), pipe(2), execve(2), execl(2), execlp(2), dup2(3c), wait(2), getenv(3c), putenv(3c) etc.
  3. One of the dangers of learning about forking processes is leaving unwanted processes active and wasting system time. Do not run these programs on armstrong: use fork.cs.buffalo.edu. Make sure each process terminates cleanly when processing is completed. The parent process should wait until the child processes complete, print a message and then quit. Do not leave behind any processes. Check for runaway processes before you log out. See kill(2), ps(1), ps(1b), sps(1), top(1), skill(1).
  4. Your program must be robust. If any of the calls fail, it should print error message and exit with appropriate error code. Always check for failure when invoking any system or library call. By convention, most UNIX calls return a value of NULL or negative one (-1) in case of an error (but always check the RETURN VALUES section of each man page for details), and you can use this information for a graceful exit. Use cerr, perror(3), or strerror(3) library routines to generate/print appropriate error messages.

    For example, something like the following (but with a real syscall name, and real bad value check):

    if (syscall(args) == BAD_VALUE) {
      perror("syscall");
      exit(1);
      }

    You will lose up to 5 points if you do not do this.



Davin Milun
Sun Sep 6 19:41:44 EDT 1998