CSE150 Operating Systems (Spring semester 2008): project 1

In this project you will write a simple Unix shell in C. The project can be done in groups of up to 2 students and is due April 30. The shell should have the following functionality:

• It reads one command line from the terminal at a time, parses it and executes it.
• The shell exits (finishes) by typing Ctrl-D on an empty line.
• The command line has the form "A | B | C | ... | Z [&]" where each of A, ..., Z is a command with parameters. The shell must set up pipelines appropriately.
• Optionally, it implements redirection, so that only A can have < and only Z can have > (otherwise, it gives an error message and doesn't run the command line).
• You don't need to implement environment variables, in particular PATH, so for testing purposes assume all executable commands (ls, grep, etc.) are in the current directory (copy them there), or give the full path when executing commands, e.g. /bin/ls -l | /bin/more.
• For errors in the command line, it prints an informative error and points to its location, e.g.:

  $ ls | | more
         ^Syntax error in pipeline.

  For errors in system calls, use perror() (see man 3 perror).

A shell can do far many more things, but you are only required to do the ones above. Your basic program should follow fig. 1-19 in the textbook; then, expand it appropriately to handle pipelines, run a process in the background, parse the command line, etc. You will need to understand well the following system calls (or similar ones): fork, execve, dup, pipe, open, close, exit, wait. To see their description and parameters, read their manual page (section 2 for system calls: man 2 fork; section 3 for library functions, e.g. man 3 perror).

The crucial bit is to get a pipeline A | ... | Z to work. First focus on understanding the simple case A | B. To get a pipeline A | B to work, you'll need to:

1. Define two file descriptors: int fd[2];
2. Create a pipe: pipe(&fd[0]);
3. Call fork() to create another process; now both processes have the same address space and file descriptors, including the pipe's.
4. For A, connect its output to the pipe's input: close(fd[0]); close(STDOUTPUT); dup(fd[1]); close(fd[1]);. Then execve A. Note that dup uses the lowest-numbered unused descriptor for the new descriptor (this will be STDOUTPUT, i.e., 1, right after closing it).
5. For B, a similar procedure but to read from the pipe.

For a more complex pipeline, apply this technique over a loop. Redirection works similarly but opening a file instead of a pipe. Other issues (e.g. how to store the command line, parse it, etc.) are left up to you; keep things simple.

Examples to try with your shell:

• ls -l
• ls -l /usr/lib | more
• ls -l /usr/lib | grep 17 | more
• cat < i.txt | sort | cut -b 10- | tail -15 | sort | cut -b 1-10 > o.txt
• cat /etc/passwd | sort | cut -b 10- | tail -15 | sort | cut -b 1-10 > o.txt
• xterm &

Your mysh should produce (almost) the same result as running them from the system shell (sh, bash, etc.).

You can use strace and ltrace to trace the calls to system calls and library functions.

What you have to submit is a single file project1.tar.gz, by email to the TA, containing:

• Your source code mysh.c (in C, not C++) and instructions on how to compile it into an executable mysh (e.g. gcc -o mysh mysh.c). We will compile it and run it. Document your code concisely.
• A concise but complete description (as a PDF file mysh.pdf) of the decisions you took as to choice of data structures, algorithms, etc. to write your code. Some issues to consider:
  • How do you store the commands in the command line?
  • How do you create the pipeline?
  • How do you deal with errors (in the command line, or in system calls)?
  • How do you deal with signals?
  • Does your shell produce exactly the same behaviour and output for a given command line as the system shell? Explain why or why not and give examples. Hint: environment variables.

UC Merced | EECS | MACP's Home Page