Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due

2024 ICS Lab4: Tiny Shell
Assigned: Dec. 02, Due: Sat, Jan. 04, 2025, 11:59PM

Introduction

The purpose of this lab is to become more familiar with the concepts of process control and signalling. You’ll do this by writing a simple Unix shell program that supports job control.

It contains 26 files, one of which is called “README”. Please read “README” to check if you have all the files.

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).

Each time you modify your tsh.c file, type make to recompile it. To run your shell, type tsh to 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 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 awaiting the next command line. Otherwise, the job runs in the foreground, which means that the shell waits for the job to terminate before awaiting 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.

tsh> jobs

tsh> /bin/ls -l -d

int main(int argc, char *argv[])

tsh> /bin/ls -l -d &

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:

• 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 file, 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 back ground. 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 integer assigned by tsh. JIDs should be denoted on the command line by the prefix ’%’. 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 bgcommand restartsby sending it a SIGCONT signal, and then runs it in the background. Theargument can be either a PID or a JID.

– The fgcommand restartsby sending it a SIGCONT signal, and then runs it in the foreground. Theargument can be either a PID or a JID.

We have provided some tools to help you check your work. Before you run any executable program,please make sure it has the execution permission. If not, use “chmod +x” to give it the execution permission.

Reference solution. The Linux executable tshref is the reference solution for the shell. Run thisprogram to resolve any questions you have about how your shell should behave. Your shell shouldemit 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 andsignals 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:

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”

unix> make test01

Similarly, to compare your result with the reference shell, you can run the trace driver on the reference shell by typing:

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 neat 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:

– 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.

The parent needs to block the SIGCHLD signals in this way in order to avoid the race condition where the child is reaped by sigchld_handler (and thus removed from the job list) before the parent calls addjob.

Here is the workaround: After the fork, but before the execve, the child process should call setpgid(0, 0), which puts the child in a new process group whose group ID is identical to the child’s PID. This ensures that there will be only one process, your shell, in the foreground process group. When you type ctrl-c, the shell should catch the resulting SIGINT and then forward it to the appropriate foreground job (or more precisely, the process group that contains the foreground job).

Your score will be computed out of a maximum of 90 points based on the following distribution:

80 Correctness: 16 trace files at 5 points each.

Your solution shell will be tested for correctness on a Linux machine, using the same shell driver and trace files that were included in your lab directory. Your shell should produce identical output on these traces as the reference shell, with only two exceptions:

We have provided you with a test le called grade-shlab.pl. Following is the example of correct case:

Hand In Instructions

We strongly recommend you to multiple commit your code to svn during implementation.