Download Notes for Lab Assignment 4 | Computer Systems and Program | CS 367 and more Study notes Computer Science in PDF only on Docsity!
CS 367, Spring 2008 Optional Lab 4 Assignment: Writing Your Own Unix Shell Due: Last class - December, 4 at 10:30am. No late submissions will be accepted.
Introduction
The purpose of this assignment is to become more familiar with the concepts of process control and signaling. You’ll do this by writing a simple Unix shell program that supports job control.
Logistics
This is NOT a group project. No collaboration between students is permitted. The only “hand-in” will be electronic. This assignment is optional, not “extra”. If you choose to submit this assignment, it will count like any other lab. Don’t submit this assignment if it will lower your overall course grade.
Hand Out Instructions
This project requires you to work on a Linux system. Start by downloading the file shlab-handout.tar to the protected directory (the lab directory) in which you plan to do your work. (You can work on Zeus.) Then do the following:
- Type the command tar xvf shlab-handout.tar to expand the tar file.
- Type the command make to compile and link some test routines.
- Type your name and login ID in the header comment at the top of tsh.c.
Looking at the tsh.c(tiny shell) file, you will see that it contains a functional skeleton of a simple Unix shell. To help you get started, we have already implemented the less interesting functions. Your assignment is to complete the remaining empty functions listed below. As a sanity check for you, we’ve listed the approximate number of lines of code for each of these functions in our reference solution (which includes lots of comments).
- eval: Main routine that parses and interprets the command line. [70 lines]
- builtin_cmd: Recognizes and interprets the built-in commands: quit, fg, bg, and jobs. [25 lines]
- do_bgfg: Implements the bg and fg built-in commands. [50 lines]
- waitfg: Waits for a foreground job to complete. [20 lines]
- sigchld_handler: Catches SIGCHILD signals. 80 lines]
- sigint_handler: Catches SIGINT (ctrl-c) signals. [15 lines]
- sigtstp_handler: Catches SIGTSTP (ctrl-z) signals. [15 lines]
Each time you modify your tsh.c file, type make to recompile it. To run your shell, type tsh on the command line:
unix> ./tsh
tsh> [type commands to your shell here]
General Overview of Unix Shells
A shell is an interactive command-line interpreter that runs programs on behalf of the user. A shell repeatedly prints a prompt, waits for a command line to be entered on stdin, and then carries out some action, as directed by the contents of the command.
The command line is a sequence of ASCII text words delimited by whitespace. The first word in the command line is either the name of a built-in command or the pathname of an executable file. The remaining words are command-line arguments. If the first word is a built-in command, the shell immediately executes the command in the current process. Otherwise, the word is assumed to be the pathname of an executable program. In this case, the shell forks a child process, then loads and runs the program in the context of the child. The child processes created as a result of interpreting a single command line are known collectively as a job. In general, a job can consist of multiple child processes connected by Unix pipes.
If the command line ends with an ampersand ”&”, then the job runs in the background, which means that the shell does not wait for the job to terminate before printing the prompt and waiting for the next command line. Otherwise, the job runs in the foreground, which means that the shell waits for the job to terminate before waiting for the next command line. Thus, at any point in time, at most one job can be running in the foreground. However, an arbitrary number of jobs can run in the background.
For example, typing the command line:
tsh> jobs
causes the shell to execute the built-in jobs command. Typing the command line
tsh> /bin/ls -l -d
runs the ls program in the foreground. By convention, the shell ensures that when the ls program begins executing its main routine
int main(int argc, char *argv[])
the argc and argv arguments have the following values:
- argc == 3,
- argv[0] == ‘‘/bin/ls’’,
- argv[1]== ‘‘-l’’,
- argv[2]== ‘‘-d’’.
Alternatively, typing the command line
tsh> /bin/ls -l -d &
runs the ls program in the background.
and print a message with the job’s PID and a description of the offending signal.
Checking Your Work
We have provided some tools to help you check your work.
Reference solution. The Linux executable tshref is the reference solution for the shell. Run this program to resolve any questions you have about how your shell should behave. Your shell should emit output that is identical to the reference solution (except for PIDs, of course, which change from run to run).
Shell driver. The sdriver.pl program executes a shell as a child process, sends it commands and signals as directed by a trace file, and captures and displays the output from the shell. Use the -h argument to find out the usage of sdriver.pl:
unix> ./sdriver.pl -h Usage: sdriver.pl [-hv] -t -s -a Options: -h Print this message -v Be more verbose -t Trace file -s Shell program to test -a Shell arguments -g Generate output for autograder
We have also provided 16 trace files (trace{01-16}.txt) that you will use in conjunction with the shell driver to test the correctness of your shell. The lower-numbered trace files do very simple tests, and the higher-numbered tests do more complicated tests.
You can run the shell driver on your shell using trace file trace01.txt (for instance) by typing:
unix> ./sdriver.pl -t trace01.txt -s ./tsh -a "-p"
(the -a "-p" argument tells your shell not to emit a prompt), or
unix> make test
Similarly, to compare your result with the reference shell, you can run the trace driver on the reference shell by typing:
unix> ./sdriver.pl -t trace01.txt -s ./tshref -a "-p"
or
unix> make rtest
For your reference, tshref.out gives the output of the reference solution on all races. This might be more convenient for you than manually running the shell driver on all trace files.
The nice thing about the trace files is that they generate the same output you would have gotten had you run your shell interactively (except for an initial comment that identifies the trace). For example:
bass> make test ./sdriver.pl -t trace15.txt -s ./tsh -a "-p"
trace15.txt -Putting it all together
tsh> ./bogus ./bogus: Command not found. tsh> ./myspin 10 Job (9721) terminated by signal 2 tsh> ./myspin 3 & [1] (9723) ./myspin 3 & tsh> ./myspin 4 & [2] (9725) ./myspin 4 & tsh> jobs [1] (9723) Running ./myspin 3 & [2] (9725) Running ./myspin 4 & tsh> fg % Job [1] (9723) stopped by signal 20 tsh> jobs [1] (9723) Stopped ./myspin 3 & [2] (9725) Running ./myspin 4 & tsh> bg % %3: No such job tsh> bg % [1] (9723) ./myspin 3 & tsh> jobs [1] (9723) Running ./myspin 3 & [2] (9725) Running ./myspin 4 & tsh> fg % tsh> quit bass>
Hints
- Read every word of Chapter 8 (Exceptional Control Flow) in your textbook.
- Use the trace files to guide the development of your shell. Starting with trace01.txt, make sure that your shell produces the identical output as the reference shell. Then move on to trace file trace02.txt, and so on.
- The waitpid, kill, fork, execve, setpgid, and sigprocmask functions will come in very handy. The WUNTRACED and WNOHANG options to waitpidwill also be useful.
- When you implement your signal handlers, be sure to send SIGINT and SIGTSTP signals to the entire foreground process group, using ”-pid” instead of ”pid” in the argument to the kill function. The sdriver.pl program tests for this error.
- One of the tricky parts of the assignment is deciding on the allocation of work between the waitfg and sigchld_handler functions. We recommend the following approach:
- In waitfg, use a busy loop around the sleep function.
- In sigchld_handler, use exactly one call to waitpid. While other solutions are possible, such as calling waitpid in both waitfg and sigchld_handler, these can be very confusing. It is simpler to do all reaping in the handler.
