[Solved] CS 160 Assignment 2: Implementing a Shell

IntroductionThe purpose of this assignment is to become more familiar with the concepts of process control and signalling.Youll do this by writing a simple Unix shell program that supports job control.Hand Out InstructionsStart by copying the file shlab-handout.tar to the protected directory (the lab directory) in whichyou plan to do your work. Then do the following: Type the command tar xvf shlab-handout.tar to expand the tarfile. Type the command make to compile and link some test routines. Type your name and 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 Unixshell. To help you get started, we have already implemented the less interesting functions. Your assignmentis to complete the remaining empty functions listed below. As a sanity check for you, weve listed theapproximate number of lines of code for each of these functions in our reference solution (which includeslots 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. [25lines] 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]1Each time you modify your tsh.c file, type make to recompile it. To run your shell, type tsh to thecommand line:unix> ./tshtsh> [type commands to your shell here]General Overview of Unix ShellsA shell is an interactive command-line interpreter that runs programs on behalf of the user. A shell repeatedlyprints a prompt, waits for a command line on stdin, and then carries out some action, as directed bythe contents of the command line.The command line is a sequence of ASCII text words delimited by whitespace. The first word in thecommand line is either the name of a built-in command or the pathname of an executable file. The remainingwords are command-line arguments. If the first word is a built-in command, the shell immediately executesthe command in the current process. Otherwise, the word is assumed to be the pathname of an executableprogram. In this case, the shell forks a child process, then loads and runs the program in the context of thechild. The child processes created as a result of interpreting a single command line are known collectivelyas 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 thatthe shell does not wait for the job to terminate before printing the prompt and awaiting the next commandline. Otherwise, the job runs in the foreground, which means that the shell waits for the job to terminatebefore awaiting the next command line. Thus, at any point in time, at most one job can be running in theforeground. However, an arbitrary number of jobs can run in the background.For example, typing the command linetsh> jobscauses the shell to execute the built-in jobs command. Typing the command linetsh> /bin/ls -l -druns the ls program in the foreground. By convention, the shell ensures that when the program beginsexecuting its main routineint 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.2Alternatively, typing the command linetsh> /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 backgroundand foreground, and to change the process state (running, stopped, or terminated) of the processesin a job. Typing ctrl-c causes a SIGINT signal to be delivered to each process in the foreground job. Thedefault action for SIGINT is to terminate the process. Similarly, typing ctrl-z causes a SIGTSTP signalto be delivered to each process in the foreground job. The default action for SIGTSTP is to place a processin the stopped state, where it remains until it is awakened by the receipt of a SIGCONT signal. Unix shellsalso provide various built-in commands that support job control. For example: jobs: List the running and stopped background jobs. bg <job>: Change a stopped background job to a running background job. fg <job>: Change a stopped or running background job to a running in the foreground. kill <job>: Terminate a job.The tsh SpecificationYour 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 separatedby one or more spaces. If name is a built-in command, then tsh should handle it immediatelyand wait for the next command line. Otherwise, tsh should assume that name is the path of anexecutable file, which it loads and runs in the context of an initial child process (In this context, theterm 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 foregroundjob, as well as any descendents of that job (e.g., any child processes that it forked). If there isno 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 identified by either a process ID (PID) or a job ID (JID), which is a positive integerassigned by tsh. JIDs should be denoted on the command line by the prefix %. For example, %5denotes JID 5, and 5 denotes PID 5. (We have provided you with all of the routines you need formanipulating the job list.)3 tsh should support the following built-in commands: The quit command terminates the shell. The jobs command lists all background jobs. The bg <job> command restarts <job> by sending it a SIGCONT signal, and then runs it inthe background. The <job> argument can be either a PID or a JID. The fg <job> command restarts <job> by sending it a SIGCONT signal, and then runs it inthe foreground. The <job> 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 thatit didnt catch, then tsh should recognize this event and print a message with the jobs PID and adescription of the offending signal.Checking Your WorkWe 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 programto resolve any questions you have about how your shell should behave. Your shell should emit output that isidentical 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 signalsas 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 -hUsage: sdriver.pl [-hv] -t <trace> -s <shellprog> -a <args>Options:-h Print this message-v Be more verbose-t <trace> Trace file-s <shell> Shell program to test-a <args> Shell arguments-g Generate output for autograderWe have also provided 16 trace files (tracef01-16g.txt) that you will use in conjunction with the shelldriver to test the correctness of your shell. The lower-numbered trace files do very simple tests, and thehigher-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), orunix> make test014Similarly, to compare your result with the reference shell, you can run the trace driver on the reference shellby typing:unix> ./sdriver.pl -t trace01.txt -s ./tshref -a -porunix> make rtest01For your reference, tshref.out gives the output of the reference solution on all races. This might bemore convenient for you than manually running the shell driver on all trace files.The neat thing about the trace files is that they generate the same output you would have gotten had you runyour shell interactively (except for an initial comment that identifies the trace). For example:bass> make test15./sdriver.pl -t trace15.txt -s ./tsh -a -p## trace15.txt Putting it all together#tsh> ./bogus./bogus: Command not found.tsh> ./myspin 10Job (9721) terminated by signal 2tsh> ./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 %1Job [1] (9723) stopped by signal 20tsh> jobs[1] (9723) Stopped ./myspin 3 &[2] (9725) Running ./myspin 4 &tsh> bg %3%3: No such jobtsh> bg %1[1] (9723) ./myspin 3 &tsh> jobs[1] (9723) Running ./myspin 3 &[2] (9725) Running ./myspin 4 &tsh> fg %1tsh> quitbass>5Hints Use the trace files to guide the development of your shell. Starting with trace01.txt, makesure that your shell produces the identical output as the reference shell. Then move on to trace filetrace02.txt, and so on. The waitpid, kill, fork, execve, setpgid, and sigprocmask functions will come in veryhandy. The WUNTRACED and WNOHANG options to waitpid will also be useful. When you implement your signal handlers, be sure to send SIGINT and SIGTSTP signals to the entireforeground 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 waitfgand 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. In eval, the parent must use sigprocmask to block SIGCHLD signals before it forks the child,and then unblock these signals, again using sigprocmask after it adds the child to the job list bycalling addjob. Since children inherit the blocked vectors of their parents, the child must be sureto then unblock SIGCHLD signals before it execs the new program.The parent needs to block the SIGCHLD signals in this way in order to avoid the race condition wherethe child is reaped by sigchld handler (and thus removed from the job list) before the parentcalls addjob. Programs such as more, less, vi, and emacs do strange things with the terminal settings. Dontrun these programs from your shell. Stick with simple text-based programs such as /bin/ls,/bin/ps, and /bin/echo. When you run your shell from the standard Unix shell, your shell is running in the foreground processgroup. If your shell then creates a child process, by default that child will also be a member of theforeground process group. Since typing ctrl-c sends a SIGINT to every process in the foregroundgroup, typing ctrl-c will send a SIGINT to your shell, as well as to every process that your shellcreated, which obviously isnt correct.Here is the workaround: After the fork, but before the execve, the child process should callsetpgid(0, 0), which puts the child in a new process group whose group ID is identical to thechilds PID. This ensures that there will be only one process, your shell, in the foreground processgroup. When you type ctrl-c, the shell should catch the resulting SIGINT and then forward itto the appropriate foreground job (or more precisely, the process group that contains the foregroundjob).6