Home | | Schedule | | Assignments | | Lecture Notes
First checkpoint due: Friday, Feb 18 (see below)
Full Project Due date: Friday, Feb 25
When each process wakes up from sleeping, it should terminate itself.
Use the process program to answer the following questions:
to determine the ID of each process and it's parent (PID and PPID). Copy and paste the output of ps -l to a text editor and save it as process_ps.txt. (You will turn this in). Use the ID's to draw a diagram of the process tree that your program generates. Make sure to indicate the ID of each process on your diagram, and make the ID's and parent-child relationships consistent with the information in your process_ps.txt file.
(Read the manual page in Unix on process status, i.e., man ps, and learn how to interpret the meaning of each column in the output of the ps -l command. Also read the man page on kill.)
Be as precise as possible when discussing the answers to these four questions.
CAUTION: Before you log out or try another test execution, always use ps to ensure that all the processes you have previously created are no longer executing.
Note: You will need the following include files for process.cc:
Turn in:
Suppose you work for a company that is in the process of creating the ULTIMATE Operating System (UOS). One goal of this OS is to provide different shells for the users, some of which will offer numerous functionality and others that will not. You are in charge of developing the tiny shell (tsh). In order to complete your task, you'll need to become familiar with input/output redirection, fork, exec, pipes, and environment variables. Your tsh needs to be rewritten in C++, and the source code should be placed in a file named tshell.cc.
The basic ground rules for the development of your tsh is that your program cannot exec (any variant) the sh program. In other words, your tsh must be stand alone; it can not rely upon another shell to function, Thus, YOUR program (and not some other program) must manipulate the file descriptors, set up and break down the pipes, etc. Your boss for UOS wants to ensure your code can handle the following capabilities:
The current value of the working directoryis obtained through getenv. For example:
will return a pointer to a string containing the current working directory.
As in most shells, the valid input to tsh will consist of, from left to right,
the commands to be executed along with their parameters connected by
pipe symbols, with any I/O redirection occurring on the far right of
the line. I/O redirection can occur in either order. For example,
either
should produce the same result. You should assume that any input file redirection is for the first command and any output file redirection is for the last command.
You don't have to do any error checking. Error handling is an important part of any program that will be widely used; however, it adds substantially to the complexity of the program. Thus, your boss wants the first draft (i.e., what is submitted) of your tsh without any error handling. In other words, your tiny shell will only be tested with valid input.
The commands listed above are only to illustrate how your tsh should function. While not needed to develop your tiny shell, you are welcome to read the manual pages on any of the above commands that are unfamiliar. I do suggest, however, that you check out the manual pages for the following commands: waitpid, dup, open, and close.
The parser
To help you with your program, you are provided with a Parser class, written by
Nick Bauer at the Colorado School of Mines, that will
take a command line and divide it up into its relevant components. The Parser class
is contained in the files:
You may copy these files from the directory ~csci346/projects/project2. You should study the description of the Parser class in parser.h and examine the data available to you in this class. Briefly, the Parser class provides a method,
that takes a command line string and parses it into its component commands (up to 10, but you will only need 2) and any input or output redirection (including a boolean to indicate if the output should be appended or not to the output file), and the input and output file names (if any). It also has a flag that indicates whether the command line should be run in the background. Commands are stored in an array of structs (type: CommandLine). Each struct has the name of the command, a list of arguments for that command (args), and the number of arguments. Note that the command name is the first argument in the list, so args can be used like argv (very useful when using execvp). Finally, numCommands gives the total number of commands minus 1 (i.e. if there is 1 command in the line, numCommands is 0).
Completed project:
Constance Royden--croyden@mathcs.holycross.edu
Computer Science 346--Operating Systems
Date Created: January 9, 2004
Last Modified: February 10, 2005
Page Expires: January 8, 2006