this is a CS program

Overview

In this assignment you will write your own shell in C. The shell will run command line

instructions and return the results similar to other shells you have used, but without many

of their fancier features.

In this assignment you will write your own shell, called smallsh. This will work like the

bash shell you are used to using, prompting for a command line and running commands,

but it will not have many of the special features of the bash shell.

Your shell will allow for the redirection of standard input and standard output and it will

support both foreground and background processes.

Your shell will support three built in commands: exit, cd, and status. It will also support

comments, which are lines beginning with the # character.

Specifications

All execution, compiling, and testing of this program should be done from the bash

prompt on the eos-class.engr.oregonstate.edu server.

Use the colon : symbol as a prompt for each command line. Be sure you flush out the

prompt each time you print it, this makes the test script look nicer.

The general syntax of a command line is:

command [arg1 arg2 ...] [< input_file] [> output_file] [&]

…where items in square brackets are optional. You can assume that a command is made

up of words separated by spaces. The special symbols <, >, and & are recognized, but

they must be surrounded by spaces like other words. If the command is to be executed in

the background, the last word must be &. If standard input or output is to be redirected,

the > or < words followed by a filename word must appear after all the arguments. Input

redirection can appear before or after output redirection.

Your shell does not need to support any quoting; so arguments with spaces inside them

are not possible.

Your shell should support command lines with a maximum length of 2048 characters, and

a maximum of 512 arguments. You do not need to do any error checking on the syntax of

the command line.

Command Execution

You will use fork, exec, and waitpid to execute commands. The shell will wait for

completion of foreground commands (commands without the &) before prompting for the

next command. The shell will not wait for background commands to complete.

Background commands should have their standard input redirected from /dev/null if the

user did not specify some other file to take standard input from. What happens to

background commands that read from standard input if you forget this?

Your shell should use the PATH variable to look for commands, and it should allow shell

scripts to be executed (see below for the testing script, for example). The right version

of the exec function will do this for you automatically. If a command fails because the

shell could not find the command to run, then the shell will print an error message and set

the exit status to 1.

After the fork but before the exec you must do any input/output redirection. A redirected

input file should be opened for reading only; if your shell cannot open the file for reading

it should print an error message and set the exit status to 1. A redirected output file

should be opened for write only, it should be truncated if it already exists or created if it

does not exist. If your shell cannot open the output file it should print an error message

and set the exit status to 1.

The built-in command status can be used to print the exit status of the last foreground

command. If a command (either a foreground or background command) is terminated by

a signal, a message indicating which signal terminated the process will be printed. The

shell will print the process id of a background process when it begins. When a

background process terminates, a message showing the process id and exit status will be

printed. You should check to see if any background processes completed just before you

prompt for a new command and print the message then. In this way the messages about

completed background processes will not appear during other running commands, though

the user will have to wait until they complete some other command to see these messages

(this is the way the C shell and Bourne shells work). You will need to use waitpid to

check for completed background processes.

Be sure that a CTRL-C interrupt from the keyboard does not terminate your shell, but

only the foreground command it is running.

Background processes should not be terminated by a CTRL-C signal, nor should they

send their standard output to the screen (consider /dev/null, instead, as needed).

Built-in Commands

Your shell will support three built in commands: exit, cd, and status.

The exit command exits the shell. It takes no arguments. When run, it must kill any

other processes or jobs that your shell has started before it terminates your shell itself.

The cd command changes directories. By itself, it changes to the directory specified in

the HOME environment variable. It can also take one argument, the path of the directory

to change to. Note that this is a working directory: when smallsh exits, the pwd will be

the original pwd when smallsh was launched. Your cd command should support both

absolute and relative paths.

The status command prints out the exit status or terminating signal of the last foreground

process. You do not have to support input/output redirection for these built in commands

and they do not have to set any exit status.

These three built-in commands are the only ones that your shell will handle itself - all

others are simply passed on to a member of the exec() family of functions (which

member is up to you).

Finally, your shell should allow blank lines and comments. Any line that begins with the

# character is a comment line and should be ignored. A blank line (one without any

commands) should do nothing; your shell should just reprompt for another command.

Example

Here is an example:

$ smallsh

: ls

junk smallsh smallsh.c

: ls > junk

: status

exit value 0

: cat junk

junk

smallsh

smallsh.c

: wc < junk

3 3 23

: test -f badfile

: status

exit value 1

: wc < badfile

smallsh: cannot open badfile for input

: status

exit value 1

: badfile

badfile: no such file or directory

: sleep 5

^Cterminated by signal 2

: status

terminated by signal 2

: sleep 15 &

background pid is 4923

: ps

PID TTY TIME CMD

4923 pts/4 0:00 sleep

4564 pts/4 0:03 tcsh-6.0

4867 pts/4 1:32 smallsh

:

:

: # that was a blank command line, this is a comment line

background pid 4923 is done: exit value 0

: # the background sleep finally finished

: sleep 30 &

background pid is 4941

: kill -15 4941

background pid 4941 is done: terminated by signal 15

: pwd

/nfs/stak/faculty/b/brewsteb/CS344/prog3

: cd

: pwd

/nfs/stak/faculty/b/brewsteb

: cd CS344

: pwd

/nfs/stak/faculty/b/brewsteb/CS344

: exit

$

In addition to your shell needing to replicate the above example in functionality, this

assignment is provided with the actual grading test script that will be used to assign

your program a grade. To run it, place it in the same directory as your compiled shell, and

run this command from a bash prompt:

$ p3testscript 2>&1

or

$ p3testscript 2>&1 | more

or

$ p3testscript > mytestresults 2>&1

Don’t worry if the spacing, indentation, or look of the output of the script is different than

when you run it interactively: that won’t affect your grade. The script may add extra

colons at the beginning of lines or do other weird things. Use it to prepare for your grade,

but base the look and feel of your program on the interactive running of your shell

What to submit

Please submit a single zip file of your program code, which may be in as many different

files as you want. Also, inside that zip file, provide a file called readme.txt that contains

instructions on HOW to compile your code; you may compile your code however you

wish. DO NOT include a copy of the testing script.

The graders will compile your code according to your exact specifications. They will

make a reasonable effort to make it work, but if it doesn’t compile, you’ll receive a zero

on this assignment.

Hints

I HIGHY recommend that you develop this program directly on the eos-class server.

Doing so will prevent you from having problems transferring the program back and forth,

and having compatibility problems.

If you do see ^M characters all over your files, try this command:

$ dos2unix bustedFile

Grading

Once the program is compiled, according to your specifications, your shell will be

executed to run a few sample commands against (ls, status, exit, in that order). If the

program does not successfully work on those commands, it will receive a zero. If it works,

it will have the p3testscript program ran against it (as detailed above) for final grading.

Points will be assigned according to the test script.

150 points are available in the test script, while the final 10 points will be based on your

style, readability, and commenting. Comment well, often, and verbosely: we want to see

that you are telling us WHY you are doing things, in addition to telling us WHAT you are

doing.