Assignment 3

Extending the shell

Deadline: 22nd September, Friday, 9pm.

You will continue to work with your Assignment 2 teammate.

The goal of this assignment is to enhance your user defined interactive shell program so that it can
handle background and foreground processes and handle signals sent to them. It should also be able
to handle input/output redirections and pipes.

The following are the specifications for the assignment. For each of the requirement an
appropriate example is given along with it.

Specification 1: Foreground and background processes

Apart from the user defined commands, all other commands are treated as system commands like:
emacs, vi and so on. The shell must be able to execute them either in the background or in the
foreground.

Foreground processes: For example, executing a "vi" command in the foreground implies that your shell will
wait for this process to complete and regain control when this process exits.
Background processes: Any command invoked with "&" is treated as background command. This implies
that your shell will spawn that process and doesn't wait for the process to exit. It will keep taking user
commands. If the background process exits then the shell must display the appropriate message to the
user.

E.g
<NAME@UBUNTU:~>ls &
This command when finished, should print its result to stdout.
<NAME@UBUNTU:~>emacs &
<NAME@UBUNTU:~>ls -l -a
.
.
. Execute other commands
.
.
<NAME@UBUNTU:~>echo hello

As and when emacs exits, your shell program should check the exit status of emacs and print it
on stderr
<NAME@UBUNTU:~>
emacs with pid 456 exited normally
<NAME@UBUNTU:~>
Specification 2: Implement input-output redirection functionality

Output of running one (or more) commands must be redirected to a file. Similarly, a command might
be prompted to read input data from a file and asked to write output to another file. Appropriate
error handling must be done (like if the input file does not exist display error message, if output file
does not exist - create one with permissions of 644, etc.)

E.g. Output redirection

<NAME@UBUNTU:~>diff file1.txt file2.txt > output.txt
E.g. Input redirection
<NAME@UBUNTU:~>sort < lines.txt
E.g. Input-Output redirection
<NAME@UBUNTU:~>sort < lines.txt > sortedlines.txt

Note: There is another clause for output direction '>>', and that must be implemented appropriately.

Specification 3: Implement command redirection using pipes

A pipe is identified by "|". One or more commands can be piped as the following examples show.
Your program must be able to support any number of pipes.
E.g. Two Commands
<NAME@UBUNTU:~>more file.txt | wc
E.g. Three commands
<NAME@UBUNTU:~>grep "new" temp.txt | cat - somefile.txt | wc

Specification 4: Implement i/o redirection + pipes redirection

E.g.
<NAME@UBUNTU:~>ls | grep *.txt > out.txt
<NAME@UBUNTU:~>cat < in.txt | wc -l > lines.txt

Hint: treat input output redirection as an argument to the command and handle it appropriately

Specification 5: User-defined commands

The following commands must be supported by the shell

-setenv var [value] : If environment variable var does not exist, then your shell must create it. Your
shell must set the value of var to value, or to the empty string if value is omitted. Initially, your shell
inherits environment variables from its parent. Your shell must be able to modify the value of an
existing environment variable or create a new environment variable via the setenv command. Your
shell must be able to set the value of any environment variable; It is an error for a setenv command
to have zero or more than two command-line arguments.

-unsetenv var : Your shell must destroy the environment variable var. It is an error for an unsetv
command to have zero command-line arguments.
-jobs : prints a list of all currently running jobs along with their pid, in particular, background jobs, in
order of their creation along with their state Running or Stopped.
<NAME@UBUNTU:~>jobs
[1] Running emacs Assign.txt [221]
[2] Running firefox [430]
[3] Running vim [3211]
[4] Stopped gedit [3213]
Here [4] i.e. gedit is most recent background job, and the oldest one is [1] emacs.

-kjob <jobNumber> <signalNumber> : takes the job id of a running job and sends a signal value to
that process
<NAME@UBUNTU:~>kjob 2 9
it sends SIGKILL to the process firefox, and as a result it is terminated. Here 9 represents the signal
number, which is SIGKILL. For further info, lookup man 7 signal

-fg <jobNumber> : brings a running or a stopped background job with given job number to
foreground.
<NAME@UBUNTU:~>fg 3
Either brings the 3rd job which is vim to foreground or returns error if no such background number
exists.

-bg <jobNumber> : changes a stopped background job to a running background job.

<NAME@UBUNTU:~>bg 4
Changes gedit from Stopped in the background to Running in the background or return error if no
such stopped background job exists. If that job is already running, do nothing.

-overkill : kills all background process at once.

-quit : exits the shell. Your shell should exit only if the user types this "quit" command. It should
ignore any other signal from user like : CTRL-D, CTRL-C, SIGINT, SIGCHLD etc.

-CTRL-Z : It should change the status of currently running job to stop, and push it in
background process.

-CTRL-C : It should cause a SIGINT signal to be sent to the current foreground job of your shell.
If there is no foreground job, then the signal should not have any effect.

Important Note for CTRL-C When you run your shell from the standard Unix shell, your shell
is running in the foreground process group. If your shell forks any child processes, they will also
be a part of the foreground process group. Typing in a CTRL-C sends a SIGINT to every process
in the foreground group, including your shell, which is not the desired behaviour here. What is
desired is for the SIGINT to be sent only to your shells foreground child processes (if any). Find
a workaround for this and implement it your shell should only exit when quit is typed.
General notes

1. Use of popen, pclose, system() calls is not promoted, your marks will be deducted if you
use any of these.
2. Useful commands : getenv, signal, dup2, wait, waitpid, getpid, kill, execvp, malloc, strtok,
fork, setpgid, setenv and so on.
3. Use exec family of commands to execute system commands. If the command cannot be
run or returns an error it should be handled appropriately. Look at perror.h for
appropriate routines to handle errors.
4. Use fork() for creating child processes where needed and wait() for handling child
processes.
5. Use signal handlers to process signals from exiting background processes.
6. The user can type the command anywhere in the command line i.e., by giving spaces,
tabs etc. Your shell should be able to handle such scenarios appropriately.
7. The user can type in any command, including, ./a.out, which starts a new process out of
your shell program. In all cases, your shell program must be able to execute the
command or show the error message if the command cannot be executed.
8. If code doesn't compile it is zero marks.
9. Segmentation faults at the time of grading will be penalized.
10. You are encouraged to discuss your design first before beginning to code. Discuss your
issues on portal and contact us, if you find any problem.
11. You are supposed to work together but implement your code in such a way that you
know what your teammate is doing and vice versa, to maximize the learning aspect.
Please adhere to the anti-plagiarism policies of the course and the institute.
12. Do not take codes from seniors or in some case, your batchmates, by any chance. We
will evaluate cheating scenarios along with previous few year submissions (MOSS).
13. Viva will also be conducted during the evaluation related to your code and also the
logic/concept involved. If youre unable to answer them, youll get no marks for that
feature/topic that youve implemented.

Submission Guidelines
- Upload format rollnum1_rollnum2_assgn2.tar.gz. Only a single member of the team needs to
upload.
- Make sure you write a makefile for compiling all your code (with appropriate flags and linker
options)
- Include a readme briefly describing your work and which file corresponds to what part.
OS TAs, ICS231