600.211: Unix Systems Programming

Fall Semester 2005: September 8, 2005 - December 12, 2005

Assignment 3: Shell

Out on: October 3, 2005
Due by: October 16, 2005 by 5:59 pm for full credit (11:59 pm for 10% off, hard deadline)
Collaboration: Pairs
Grading: Packaging 10%, Style 10%, Performance 10%, Design 20%, Functionality 50%

Overview

The third assignment for 600.211: Unix Systems Programming is all about writing your own shell. Note that you still might find a few uses for your hash tables, but we'll be a little more "Unixy" for the next two weeks. You'll need a partner for this one again, watch out for details on the course mailing list.

The assignment comes in two parts, mostly to help you decide how much effort you want to put into it. In the first part you implement the basic functionality of a shell, in the second part you extend the shell in various ways.

Problem 1: Core

A shell is the most common interface between a Unix user and the Unix system. It is responsible for parsing and executing your commands. A minimalist shell will do nothing more than this, a good one will add file redirection, pipes, backticks, environment variables, aliases, wildcard expansion, running commands in the background, a command history, and a host of other features.

Your shell should not make use of existing "shell-like" functionality, you should build everything from "ground up" using basic system calls; if in doubt, a quick email to the discussion list might be a good idea before you start using something we'll deduct points for. Anyway, here are the core features that your shell must implement.

prompt for a command and read a command
parse the command (setting up argc and argv) and execute the command
support the PATH environment variable as expected of a shell
make sure that signals are handled as expected of a shell
the "cd" command to change the current working directory; be sure to handle all relevant errors for this (not a directory, permission denied, file not found, etc)

Not much to do for a basic shell, is there? But if you feel tired for some reason, this at least gets you half of the points (provided you do it correctly of course).

Problem 2: Extensions

Here is where the fun part of the assignment starts. You can try to implement as many of these as you like. Just be sure to document all the functionality you have implemented in your README file so we know what to look for.

Implement pipes, that is the "|" operation. For a command string "A | B", let A's standard output feed into B's standard input. You should handle repeated pipes as in "du | sort -rn | less" as well.
Implement backticks, that is the "`" operation. For a quick introduction compare echo uname against echo 'uname' agains echo `uname`. Or google for it.
Implement file redirection, that is the "<", ">", and ">>" operations. For example "ls > foo should store the directory listing in the file foo.
Implement background commands, that is the "&" operation. Check for backgrounded process termination each time before printing your shell prompt and print out a message for each process that terminated.
Implement wildcard substitution or globbing. This is similar to yet different from regular expressions. If there are files 1.txt and 10.txt in the current directory, the command "A ?.txt" should expand to "A 1.txt" while the command "A *.txt" should expand to "A 1.txt 10.txt" instead. An asterisk stands for "zero or more" letters, while a question mark stands for "exactly one" letter.
Implement a command history. The up and down arrow keys should scroll through a history of the last 100 or so commands that you have entered.
Implement escape characters. For whitespace and any special characters that you have implemented, if they are preceded by a "\", then interpret them as non-special characters.
Implement aliases. Use either bash or tcsh syntax.
Implement environment variables. Use either bash or tcsh syntax.
Implement environment variable substitution. Replace "$NAME" with the value of the variable NAME. You should allow for substitution everywhere it is sensible, using the "${NAME}" syntax if necessary. Experiment with bash if necessary.

If you have implemented something in addition to all these features, be sure you explain how to use your feature in your README file.

Hints

Feel free to use the GNU getopt library for command line arguments.
Feel free to use the functions for error handling from our text, and (of course) actually handle all error conditions that can arise.
Remember that you can put shell commands into a file and then do "sh file" to run them?

Deliverables

Please turn in a gzip compressed tarball of your assignment (the extension should be .tar.gz). The tarball should uncompress into a directory cs221-assignment-3-login with login replaced by your Unix login name (so I would use cs211-assignment-3-phf); uncompressing should not create any other files in the current directory. The tarball should contain no derived files whatsoever, but allow building all derived files with make. We expect that your Makefile handles "the usual" targets like clean and test aside from all (which is the main way we will build your program). Include a README file that briefly explains what the program does and contains any other notes you want us to check out before grading; make sure the README lists both partners in a pair! Include other "common" files such as INSTALL describing how to install your tool, CREDITS to pay your respects to the people whose code you're reusing, and LICENSE to describe copyright and distribution terms if you feel like it. You can look at any number of "famous" open source projects to see what kind of structure is appropriate; gif2png is a relatively small example, but you don't need everything in there. Aside from your code, what you really need is a README and a Makefile that works. :-)

Grading

For reference, here is a short explanation of the grading criteria. Packaging refers to the proper organization of the stuff you hand in, following the guidelines for Deliverables above. Style refers to C programming style, including things like consistent indentation, appropriate identifiers, useful comments, etc. Simple, clean, readable code is what you should be aiming for. Performance refers to how fast your program can produce the required results compared to other submissions. Design refers to proper modularization and the proper choice of algorithms and data structures; often this can be judged by asking "How hard would it be to add feature X?" and "How hard is it to replace algorithm X with algorithm Y?". Functionality refers to your program being able to do what it should according to the specification given above; if the specification is ambiguous and you had to make a certain choice, defend that choice in your README file.

If your program cannot be built you will get no points whatsoever. If your program cannot be built using make we will take off 10%. If your program cannot be build without warnings using gcc -W -Wall -O -ansi -pedantic we will take off 10% (except if you document a very good reason). If your program fails miserably even once, e.g. segfaults or runs forever, we will take off 10%.

Bonus Feature

If you really want to impress us, add some kind of "cool" bonus feature to your program. We won't give you extra points, but we'll give you extra kudos. :-) Be sure to point out any bonus features you have in your README file. Reading the man pages for bash or tcsh or zsh or fish or whatever should provide plenty of ideas. For various reasons I think a full-screen curses-based shell with screen splitting and status lines would be cool... :-)

Kudos

This assignment is based on a similar assignment designed by Titus Winters at the University of California, Riverside. Thanks a bunch, dude! :-)