CSE 361s Fall 2022 Extra Credit Lab: Writing a Unix Shell
ntroduction
This is an extra credit lab. The lab will be graded according to the specififications laid out in this document,and it can add up to 1.5% to your overall course grade. Doing this lab will help you become more familiar with process control and signaling. You’ll do this by writing a simple Unix shell program that supports job control.
Git Instructions
You can accept the assignment and obtain your starter code by going to the GitHub Classroom URL:
https://classroom.github.com/a/BeBQvxZz.
Handin Instructions
As usual, your handin will consist of two parts: a submission to the Autolab server and a commit to your GitHub repository.
For both turnins, the fifile tsh.c is the only fifile that will be submitted and that the grader will consider, so please do NOT include code in any other fifile.
As always, your code will earn zero credit if it does not successfully compile on a linuxlab machine.
For this lab, the Autolab server will be used for handins, but no autograder will run on the server and no scoreboard will be posted. Instead, you can check your code using the scripts provided in the repository on a linuxlab machine.
To compile your code, go to the assignment directory and type:
linux> make clean
linux> make
To hand in your code, simply push the modifified tsh.c to your git repository and submit it to the Autolab server.
A driver program sdriver.pl, a script checktsh.pl, and a set of traces have been provided to you to test the correctness of your shell program.
It is your job to ensure that you have successfully pushed your code to the git repository and submitted to the Autolab server. You should always look on the web to be sure that the right version of tsh.c has been pushed successfully to the repository and uploaded to the Autolab server. It is also your job to ensure that your code compiles and runs successfully when the driver is invoked. (See the Checking Your Work section for more detail on using the driver.)
Codebase Overview
Looking at the tsh.c fifile (short for “tiny shell”), 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 fifile, 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 on stdin, and then carries out some action, as directed by the contents of the command line.
The command line is a sequence of ASCII text words delimited by whitespace. The fifirst word in the command line is either the name of a built-in command or the pathname of an executable fifile. The remaining words are command-line arguments. If the fifirst 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 awaiting the next command.
Otherwise, the job runs in the foreground, which means that the shell waits for the job to terminate before awaiting the next command. 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
tsh> jobs
causes the shell to execute the built-in jobs command. Typing the command
tsh> /bin/ls -l -d
runs the ls program in the foreground. By convention, the shell ensures that when the 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
tsh> /bin/ls -l -d &
runs the ls program in the background.
Unix shells support the notion of job control, which allows users to move jobs back and forth between background and foreground, and to change the process state (running, stopped, or terminated) of the processes in a job. Typing ctrl-c causes a SIGINT signal to be delivered to each process in the foreground job. The default action for SIGINT is to terminate the process. Similarly, typing ctrl-z causes a SIGTSTP signal to be delivered to each process in the foreground job. The default action for SIGTSTP is to place a process in the stopped state, where it remains until it is awakened by the receipt of a SIGCONT signal. Unix shells also provide various built-in commands that support job control. For example:
jobs: List the running and stopped background jobs.
bg : Change a stopped background job to a running background job.
fg : Change a stopped or running background job to a running in the foreground.
kill : Terminate a job.
The tsh Specifification
Your tsh shell should have the following features:
The prompt should be the string “tsh> ”.
The command line typed by the user should consist of a name and zero or more arguments, all separated by one or more spaces. If name is a built-in command, then tsh should handle it immediately and wait for the next command line. Otherwise, tsh should assume that name is the path of an executable fifile, which it loads and runs in the context of an initial child process (In this context, the term job refers to this initial child process).
tsh need not support pipes (|) or I/O redirection (< and >).
Typing ctrl-c (ctrl-z) should cause a SIGINT (SIGTSTP) signal to be sent to the current foreground job, as well as any descendents of that job (e.g., any child processes that it forked). If there is no foreground job, then the signal should have no effect.
If the command line ends with an ampersand &, then tsh should run the job in the background.
Otherwise, it should run the job in the foreground.
Each job can be identifified by either a process ID (PID) or a job ID (JID), which is a positive integer assigned by tsh. JIDs should be denoted on the command line by the prefifix ’%’. For example, “%5” denotes JID 5, and “5” denotes PID 5. (We have provided you with all of the routines you need for manipulating the job list.)
tsh should support the following built-in commands:
– The quit command terminates the shell.
– The jobs command lists all background jobs.
– The bg command restarts by sending it a SIGCONT signal, and then runs it in the background. The argument can be either a PID or a JID.
– The fg command restarts by sending it a SIGCONT signal, and then runs it in the foreground. The argument can be either a PID or a JID.
tsh should reap all of its zombie children. If any job terminates because it receives a signal that it didn’t catch, then tsh should recognize this event and print a message with the job’s PID and a description of the offending signal.