Princeton University
COS 217: Introduction to Programming Systems

Assignment 6: A UNIX Shell

Purpose

The purpose of this assignment is to help you learn about UNIX processes and inter-process communication. It will also give you ample opportunity to define software modules; in that sense the assignment is a capstone for the course.

Background

A UNIX shell is a program that makes the facilities of the operating system available to interactive users. There are several popular UNIX shells: sh (the Bourne shell), csh (the C shell), and bash (the Bourne Again shell) are a few.

Your Task

Your task in this assignment is to create a program named ish. ish should be a minimal but realistic interactive UNIX shell.

Initialization and Termination

When first started, ish should read and interpret lines from the file .ishrc in your HOME directory, provided that the file exists and is readable. Note the the file name is .ishrc (not ishrc), and that it resides in the user's HOME directory (not the current directory). Typically, the .ishrc file contains commands to specify the terminal type and environment.

To facilitate your debugging and our testing, ish should print each line that it reads from .ishrc immediately after reading it. ish should print a percent sign and a space (% ) before each such line.

ish should terminate when the user types Control-D or exit.

Interactive Operation

After startup processing, ish should read lines from the terminal, prompting with a percent sign and a space (% ). Specifically, ish repeatedly should perform the these actions:

Read a line from standard input.

Lexically analyze the line to form an array of tokens.

Syntactically analyze (i.e. parse) the token array to form a pipeline of commands.

Execute the pipeline.

Lexical Analysis

Informally, a token should be a word. More formally, a token should consist of a sequence of non-whitespace characters that is separated from other tokens by whitespace characters. There should be two exceptions:

The special characters '|', '<', and '>' should form separate tokens.
Strings enclosed in double quotes ( " ) should form part or all of a single token. Special characters inside of strings should not form separate tokens.

ish should assume that no line of standard input is longer than 1024 characters. If a line of standard input is longer than 1024 characters, then ish need not handle it properly; but it should not corrupt memory.

Syntactic Analysis

A command should be a sequence of tokens, the first of which specifies the command-name.

The '<' token should indicate that the subsequent token is the name of a file. ish should redirect the command's standard input from that file. It should be an error to redirect a command's standard input more than once.

The '>' token should indicate that the subsequent token is the name of a file. ish should redirect the command's standard output to that file. If the file does not already exist, then ish should create it; if the file does already exist, then ish should destroy its contents and rewrite the file from scratch. ish should set the permissions of the new file by examining the user's umask setting. It should be an error to redirect a command's standard output more than once.

A pipeline should be a sequence of one or more commands separated by '|' tokens. ish should redirect the standard output of the command that precedes the '|' token to the standard input of the command that follows. It should acceptable to redirect the standard input of the first command of a pipeline via the '<' token; it should be erroneous to redirect the standard input of any other command of a pipeline via the '<' token. Similarly it should be acceptable to redirect the standard output of the last command of a pipeline via the '>' token; it should be erroneous to redirect the standard output of any other command of a pipeline via the '>' token.

Execution

If the command is an ish built-in, then ish should execute it directly (i.e. without forking a child process). ish should interpret four shell built-in commands:

setenv var [value]	If environment variable var does not exist, then ish should create it. ish should set the value of var to value, or to the empty string if value is omitted. Note: Initially, ish inherits environment variables from its parent. ish should be able to modify the value of an existing environment variable or create a new environment variable via the setenv command. ish should be able to set the value of any environment variable; but the only environment variable that it explicitly uses is HOME.
unsetenv var	ish should destroy the environment variable var.
cd [dir]	ish should change ish's working directory to dir, or to the HOME directory if dir is omitted.
exit	ish should exit.

Note that those built-in commands should neither read from standard input nor write to standard output. Thus ish need not support file redirection with its built-in commands. Nor does ish need to support built-in commands within pipelines.

If the command is not an ish built-in, then ish should consider the command-name to be the name of a file that contains executable binary code.ish should fork a child process and pass the filename, along with its arguments, to the execvp system call. If the attempt to execute the file fails, then ish should print an error message indicating the reason for the failure.

ish should print its prompt for the next standard input line only when all commands in the current pipeline have finished executing. If any command of a pipeline fails to execute, ish should simply let all of the other commands execute to completion.

Process Control

All child processes forked by ish should run in the foreground; ish need not support background process control. However, the user must be able to kill the current child processes using Control-C. Control-C should not kill ish itself.

Error Handling

ish should handle an erroneous line gracefully by rejecting the line and writing a descriptive error message to standard error. ish should handle all user errors; it should be impossible for the user's input to cause ish to crash.

Memory Management

ish should contain no memory leaks. For every call to malloc or calloc, there should eventually be a call to free.

History Mechanism (for extra credit)

ish should support a history mechanism that includes:

A history built-in command. The history command should print a list of all previously issued commands. Note that the history command should write data to standard output, and so ish should allow it to be used with file redirection or within a pipeline.
The ability to re-execute a previously issued command by typing a prefix of that command preceded by an exclamation point (!commandprefix). Note that ish should allow use of the !commandprefix syntax with file redirection or within a pipeline.

ish need not support editing of the previously issued command.

Logistics

A Supplementary Information page is available that lists detailed implementation requirements and recommendations.

Develop on arizona. Use Emacs to create source code. Use the "make" tool to automate the build process. Use gdb to debug.

An executable version of the assignment solution is available in /u/cs217/Assignment6/sampleish. You should use it to resolve any issues concerning the desired functionality of ish.

The file /u/cs217/Assignment6/.ishrc_given is a sample initialization file. It also serves as a minimal test case. The expectation is that you will devote substantial effort to creating and running additional test cases.

You should submit:

Your source code files.
A makefile. The first dependency rule should build your entire program, compiling with the -Wall, -ansi, and -pedantic options. The makefile should maintain object (.o) files to allow for partial builds.
A readme file.

Your readme file should contain:

Your name.
A description of whatever help (if any) you received from others while doing the assignment, and the names of any individuals with whom you collaborated, as prescribed by the course "Policies" web page.
If you are submitting your work late, an indication of how many "free late days" you wish to apply to this assignment.
Optionally, an indication of how much time you spent doing the assignment.
Optionally, your assessment of the assignment.
Optionally, any information that will help us to grade your work in the most favorable light. In particular you should describe all known bugs.

Submit your work electronically via the command /u/cs217/bin/submit 6 makefile readme sourcecodefiles

Note that we are not permitted to accept any work that is submitted after the Dean's Date.

Grading

Your work will be graded on correctness, understandability, and design. An important aspect of design is proper modularity through the definition and use of interfaces and implementations. To encourage good coding practices, we will take off points based on warning messages during compilation.

Princeton University COS 217: Introduction to Programming Systems