Although we don't think about it all that often, the command shell in which you do most of your work is a marvel of presenting process and I/O management in a highly abstracted way, greatly simplifying the user's responsibilities in launching and managing processes. As we can learn a great deal about a number of fundamental process management and I/O issues, it's worth our time to build a specialized command shell of our own to see what else we could do with it if we choose.

The Problem

Basic Operation

Once running your shell, the user should be able to launch programs as they do in their regular command shell. By way of reminder, a basic command to launch a program would look like:

progname arg1 arg2 ... argN

where progname is the name of a program to be executed, and arg1 arg2 ... argN are the arguments to be passed to that program (which are specific to whatever program is being launched obviously). In response to this command, the shell should arrange to spawn this process (using fork(2) and exec(2) system calls) and make whatever book-keeping updates it needs to in order to manage this process in future. Like a real shell, the shell itself should wait for the termination of this program before returning control (i.e. the prompt) to the user, while any output from that program is displayed in the shell normally.

Shell Commands

Your shell is required to support a number of more advanced features:

Piping

One program is invoked with its stdout connected to the stdin of another program (both of which are otherwise "standard commands" as described above). You will need to make use of pipe(2) and manipulation of the file descriptor tables using dup(2) or dup2(2) in order to accomplish this.

Syntax:
<standard_command> -> <standard_command>

Example:
ls -l -> sort -r

I/O redirection

You can cause a program to consume stdin from a file, or output its stdio to a file using ^ for input, and $ for output. You will need to make use of the open(2) low level I/O routine in addition to manipulation of the file descriptor table using dup(2) or dup2(2) to do this. Note it is possible to redirect either one of these, or both.

Syntax:
<standard_command> ^ <infile>
<standard_command> $ <outfile>
<standard_command> ^ <infile> $ <outfile>

Examples:
cat ^ excitingtextfile.txt
ls -l $ dirlisting.txt
sort ^ dirlisting.txt $ sorteddirlisting.txt

Note that redirection operations could occur in any order.

Background Execution

Execute the program in the background (rather than foreground), returning the user to the prompt immediately while the process they created runs in the background. Note that you do not need to do anything special with stdout of background processes (it will be the same file descriptor as the shell's, so any output will appear in your shell anyway).

Syntax:
<standard_command> !

Examples:
find . -name "*.txt" !

Efficiency enforcement

It should be possible to demand a process being started keep the processor "sufficiently busy". The idea here is to ensure a process started, subject to this constraint, lives up to its billing. This is a real issue on many systems where inefficient use of the CPU resource is not acceptable. In this case, your shell will simply enforce it. It will be necessary for your program to periodically monitor the CPU load of any process started in this manner. If its CPU load falls below the specified threshold, it should be terminated (with a message to the terminal indicating this happened). Note that a process may take a short time before it hits a steady state in terms of processor utilization; you should take this into account and not kill a just started process that is still ramping up. This information can be trivially extracted from the output of ps; have a look at popen(3) as a means of making this output available withing your program as a FILE * stream, and alarm(2) as a mechanism for triggering a handler to do regular periodic monitoring.

Syntax:
<standard_command> > <percentage

Examples:
xhpl > 90

Job groups

It is possible to use a special notation prefix while executing a program that assigns that process to a job group that allows a collection of running processes to be treated as a group for specific job control commands. There are two aspects to this behaviour:

1. Assigning a job group: applying a numbered prefix in square brackets before the standard command results in that process being assigned to that specific job group. Note that the number is arbitrary and isn't assumed to be sequential.

   Syntax:
   [<#>] <standard_command>
   

   Examples:
   [3] grep printf *.c
   

2. Job control: the following are to be interpreted as shell commands. When they appear as the first non-whitespace content in a command-line, the entire command line is to be treated as a job control directive, and the specified action taken on all processes assigned to that job group. These are ultimately just commands to have signals sent to multiple processes with a single command, and as such will require the use of kill(2). The implementation of this functionality will be greatly eased by making use of group ids as you spawn processes (see setgid(2), and understand how you can use a single kill call to send a signal to an entire group). Job control commands to be supported include:
   • jkill: terminate all jobs in the group
   • jstop: pause all jobs in the group
   • jcont: start all jobs in the group

   Syntax:
   <jobcommand> <jobgroup#>
   

   Examples:
   jstop 4
   jkill 3
   

Note that because jkill, jstop and jcont are now treated as shell commands, it wouldn't be possible for a user to run programs by those names without providing the path (again, this is nothing you really need to support specifically, just pointing it out).

Bonus

Implementation Guidelines

• To avoid this becoming a complicated exercise in parsing command-lines, you can assume input is well formatted, and that there is at least a single whitespace character between all command elements. In particular you can assume that if you want to run someprog in the background, the command would appear as "someprog !"; "someprog!" would be interpreted as a command to run something called literally "someprog!".

  Don't get too creative with this. Parsing is only hard when you think about it as "what I'd like, and then whatever exception to the norm that you can think of". State-based parsing is the simpler way to handle things. Worst case, break apart the command-line as whitespace delimited tokens, and treat the components in terms of what you'd expect in terms of the command. If there aren't enough elements present, there's an error in the command. If you attempt to process the elements as expected and get an error, you can report that.

  This doesn't excuse your program from just exploding. Any errors that can be detected should be reported as meaningfully as possible. Some errors will be implicit while processing the items (for example trying to spawn a process with a command that doesn't exist) --- these can still be reported rather than just silently failing. Please just do not get overly ornate with trying to make sense of idiosyncrasies in the command-line. The point to this assignment is not bullet-proof parsing.

• The following constraints apply to command-line elements. They apply whether you are supporting only one at a time, or allowing multiple elements to appear in a single command-line (i.e. the bonus above).
  • Job group assignment [#] can only appear as the first element of the command-line
  • Background execution ! can only appear as the last element of the command-line
  • I/O redirection ^,$ only appears after the standard command(s), but can appear alone or together and in any order
  • Efficiency enforcement > appears after the standard command(s) and I/O redirection (if present).

  So the highly general order to potential command-line could potentially look like:

  <jobgroup> <standard_command(s)> <I/O redirection> <efficiency> <background>

• You are not necessarily writing any programs to be run in this shell --- any program on the system should be able to be run within your shell. You can assume that any programs started in this way are entirely text-based (i.e. no GUI, no terminal support, etc.). Just about everything else a program does is largely agnostic to your shell. That being said, you will likely find it helpful to write small "driver" programs for testing purposes although these should not form part of the submission.

Warning: always clean up after yourself!!!

This assignment involves you explicitly using the fork() system call to create new processes, and development and testing will involve experiments with possibly many CPU-bound jobs running in the background.

1. If you make mistakes with the use of fork() it is quite possible to suck the machine on which you are running down to nothing with an exploding number of processes (the aptly-named "fork-bomb"). You are not to run this code on department equipment other than the REYN 001A lab machines which are provided for this purpose. You can run on your own computers if you like, just be aware that if you really hose them you may need to reboot.
2. Please make sure no jobs are left behind (intentionally or by accident) when you leave a workstation---this could easily affect the next person using that machine. Note that if during our testing of your program, processes are improperly left running, your mark will be reduced by 10% for each such process!

Makefile

You are responsible for writing a Makefile to compile your code. Typing "make", "make ossh" or "make all" should result in the compilation of all required components with the result being your program (ossh). You should ensure that all required dependencies are specified correctly.

Deliverables

• Source code:
  • All source code required to compile and execute your ossh program. You are encouraged to organized your code in a modular fashion so obviously header files or other source code files required for your implementation should be included.
  • Makefile
  • The required README file containing descriptions of the files you are submitting and any notes that may be relevant to the marker (e.g. compilation and execution instructions, etc.)
• Documentation:
  • Brief documentation should include:
  • Statement of the problem solved
  • Design notes: how you solved the problem (specifically, a brief description of the solution you developed to solve the problem---in this case, the manipulation of system-level book-keeping to impose behaviour on programs that no nothing of what is happening, in addition to the management of background processes in response to their CPU activity).
  • Decisions/assumptions/justifications: state any assumptions you made in solving the problem and known limitations of your implementation; justify the design decisions you made in the previous section (i.e. why a particular approach and not another?).
  • Testing: indicate what methods you have used to ensure the correct/appropriate operation of your solution.
  • Documentation can be provided in pdf or text format, and only those formats will be accepted. Do not submit Word documents or any other random things you feel like. The file should be named A2_docs.pdf or A2_docs.txt as appropriate.
• Electronic submission:
  • All of the above, including the documentation and required README file should be tar'ed, gzip'ed and submitted through the Moodle system as described in the submission guidelines for the course.