Description

Lab: Building a Shell
In this lab, you will build a simple shell to execute user commands, much like the bash shell in Linux. This lab will deepen your understanding of various concepts of process management in Linux.
Before you begin
• Familiarize yourself with the various process related system calls in Linux: fork, exec, exit and wait. The “man pages” in Linux are a good source of learning. You can access the man pages from the Linux terminal by typing man fork, man 2 fork and so on. You can also find several helpful links online (e.g., http://manpages.ubuntu.com/manpages/trusty/ man2/fork.2.html).
• Write simple programs using these system calls, as a warmup to solving this lab. For example, you can write a program that forks a child process. The child process should print some message and exit. The parent should wait to reap the child, print a message after reaping the child, and then exit. Write many such simple programs until you feel confident with the basic usage of these system calls.
• Familiarize yourself with simple shell commands in Linux like echo, cat, sleep, ls, ps, top, grep and so on. To implement these commands in your shell, you must simply “exec” these existing executables, and not implement the functionality yourself.
• Understand the chdir system call in Linux (see man chdir). This will be useful to implement the cd command in your shell.
• For part B, understand the concepts of foreground and background execution in Linux. Execute various commands on the Linux shell both in foreground and background, to understand the behavior of these modes of execution.
• For parts C and D, understand signals and signal handling in Linux. Understand how processes can send signals to one another using the kill system call. Read up on how to write custom signal handlers to “catch” signals and override the default signal handling mechanism, using interfaces such as signal() or sigaction().
• Read the problem statement fully, and build your shell incrementally, part by part. Test each part thoroughly before adding more code to your shell for the next part.
Part A: A simple shell
We will first build a simple shell to run simple Linux commands. A shell takes in user input, forks one or more child processes using the fork system call, calls exec from these children to execute user commands, and reaps the dead children using the wait system call. Your shell must execute all simple Linux commands like ls, cat, echo and sleep. These commands are readily available as executables on Linux, and your shell must simply invoke the existing executable. It is important to note that you must implement the shell functionality yourself, using the fork, exec, and wait system calls. You must not use library functions like system which implement shell commands by invoking the Linux shell—doing so defeats the purpose of this assignment!
Your simple shell must use the string “$ ” as the command prompt. Your shell should interactively accept inputs from the user and execute them. In this part, the shell should continue execution indefinitely until the user hits Ctrl+C to terminate the shell. You can assume that the command to run and its arguments are separated by one or more spaces in the input, so that you can “tokenize” the input stream using spaces as the delimiters. For this part, you can assume that the Linux commands are invoked with simple command-line arguments, and without any special modes of execution like background execution, I/O redirection, or pipes. You need not parse any other special characters in the input stream. Please do not worry about corner cases or overly complicated command inputs for now; just focus on getting the basics right.
Once you complete the execution of simple commands, proceed to implement support for the cd command in your shell using the chdir system call. The command cd <directoryname> must cause the shell process to change its working directory, and cd .. should take you to the parent directory. You need not support other variants of cd that are available in the various Linux shells. For example, just typing cd will take you to your home directory in some shells; you need not support such complex features. Note that you must NOT spawn a separate child process to execute the chdir system call, but must call chdir from your shell itself, because calling chdir from the child will change the current working directory of the child whereas we wish to change the working directory of the main parent shell itself. Any incorrect format of the cd command should result in your shell printing Shell: Incorrect command to the display and prompting for the next command.
Your shell must gracefully handle errors. An empty command (typing return) should simply cause the shell to display a prompt again without any error messages. For all incorrect commands or any other erroneous input, the shell itself should not crash. It must simply notify the error and move on to prompt the user for the next command.
To test this lab, run a few common Linux commands in your shell, and check that the output matches what you would get on a regular Linux shell. Further, check that your shell is correctly reaping dead children, so that there are no extra zombie processes left behind in the system.
Part B: Serial, parallel, and background execution
Now, we will build support for executing multiple commands at a time in your shell, as described below. Extend your shell program of part A to support the following modes of operation.
• If a command is followed by &, the command must be executed in the background. That is, the shell must start the execution of the command, and return to prompt the user for the next input, without waiting for the previous command to complete. The output of the command can get printed to the shell as and when it appears.
• Multiple user commands separated by && should be executed one after the other in sequence in the foreground. The shell must move on to the next command in the sequence only after the previous one has completed (successfully, or with errors). The shell should return to the command prompt after all the commands in the sequence have finished execution.
• Multiple commands separated by &&& should be executed in parallel in the foreground. That is, the shell should start execution of all commands simultaneously, and return to command prompt after all commands have finished execution.
• A command not followed by any of the special characters mentioned above must simply execute in the foreground as before.
A helpful tip for testing: use multiple long running commands like sleep to test your series, parallel, or background implementations, as such commands will give you enough time to run ps in another window to check that the commands as executing as specified. You should be able to run one or more sleep commands in background/series/parallel modes to verify the correctness of these implementations.
Part C: The exit command
Up until now, your shell executes in an infinite loop, and only the signal SIGINT (Ctrl+C) would have caused it to terminate. Now, you must implement the exit command that will cause the shell to terminate its infinite loop and exit. When the shell receives the exit command, it must terminate all background processes, say, by sending them a signal via the kill system call. Obviously, if the shell is receiving the comand to exit, it goes without saying that it will not have any active foreground processes running. Before exiting, the shell must also clean up any internal state (e.g., free dynamically allocated memory), and terminate in a clean manner.
Part D: Handling the Ctrl+C signal
Up until now, the Ctrl+C command would have caused your shell (and all its children) to terminate. Now, you will modify your shell so that the signal SIGINT does not terminate the shell itself, but only terminates the one or more foreground processes it is running. That is, when executing multiple commands in serial mode, the shell must terminate the current command, ignore all subsequent commands in the series, and return back to the command prompt. When in parallel mode, the shell must terminate all foreground commands and return to the command prompt. Note that the background processes should remain unaffected by the SIGINT, and must only terminate on the exit command. You will accomplish this functionality by writing custom signal handling code in the shell, that catches the Ctrl+C signal and relays it to the relevant processes, without terminating itself.
Hint: Recall that, by default, any signal like SIGINT will be delivered to the shell and all its children. To solve this part correctly, you must carefully place the various children of the shell in different process groups, say, using the setpgid system call. Note that setpgid(0,0) places a process in its own separate process group, that is different from the default process group of its parent. Your shell must do some such manipulation on the process group of its children to ensure that only a subset of the children receive the Ctrl+C signal. For example, placing all the background children in a separate process group will ensure that they do not get killed by the Ctrl+C signal immediately.
• You must submit the shell code myshell.c or myshell.cpp.
• Place this file and any other files you wish to submit in your submission directory, with the directory name being your roll number (say, 12345678).
• Tar and gzip the directory using the command tar -zcvf 12345678.tar.gz 12345678 to produce a single compressed file of your submission directory. Submit this tar gzipped file on Moodle.