Operating Systems - Projects and Exercises

This week you will be putting the finishing touches to your shell:

Script file support

Make the shell capable of taking its command line input from a file whose name is provided as a command line argument. i.e. if the shell is invoked with a command line argument:

myshell batchfile

then batchfile is assumed to contain a set of command lines for the shell to process. When the end-of-file is reached, the shell should exit. When a batch file is provided, the shell should provide no prompt.

Obviously, if the shell is invoked without a command line argument it should solicit input from the user via a prompt on the display as before.

You will probably need to have a look at the difference between the gets and fgets functions and insert a test for end-of-file for when reading from a file (int feof(FILE*)). You may find it easier to use fgets for both types of input using the default FILE stream pointer stdin when no batch file is specified. Note the use of fgets in the strtokeg.c example.

Internal Commands/Aliases:

To provide support for batch file operation, add the following internal commands:

echo <comment>

display this command line on the display (without the word echo). Remember that <comment> can be multiple words.

pause

display "Press Enter to continue..." and pause operation of the shell until 'Enter' is pressed (ignore any intervening non-'Enter' input). Turning off echo of keyboard input is possible and there is also a system function to read a buffer from the current tty input without echo - this is left as a research exercise for the student!

To comply with the project specifications you also need to provide a help command that will print out your readme file. Note that you may not actually still be in the 'startup' directory! Although you can assume that the readme file will be in the current working directory when the shell is started.

Background Execution of External Commands:

Having put in the wait function to ensure that the child process finishes before the shell gets its next command line, you will now have to provide the option of 'background' operation. i.e. the child is started and then control by-passes the wait function to be immediately passed back to the shell to solicit the next command line.

An ampersand (&) at the end of the command line indicates that the shell should return to the command line prompt immediately after launching that program. You can assume that & will be surrounded by white space (' ', '\t', or '\n') and will be the last non-white space character in the line.

makefile Support

Marking the project will entail the marker recompiling your source code from scratch. To automate this process, a requirement of the project is that your shell must be able to be built using a make file. If you are using two source files myshell.c and utility.c, both of which reference the local 'include' file myshell.h, then your makefile should look like this:

# Joe Citizen, s1234567 - Operating Systems Project 1
# CompLab1/01 tutor: Fred Bloggs
myshell: myshell.c utility.c myshell.h
       gcc -Wall myshell.c utility.c -o myshell 

Then your shell program is re-built by just typing make at the command prompt if any of the .c or .h files have been changed since the last time the shell was built.

Note that this makefile names the resulting executable file as myshell, another requirement of the project.

Note also that the third line of the above makefile - gcc -Wall myshell... - the action line - must start with a tab.

Polishing:

1. Check that arguments exist before accessing them.
2. What happens when Ctrl-C is pressed during
   1. command execution?
   2. user entry of commands?
   3. would SIGINT trapping control this better?
3. Check existence of input redirection files
4. Check makefile works
5. Ensure that all files are named as requested

readme file:

Make sure this complies with the requirements.

Re-read the project specifications and ensure that you really do comply with what is requested NOT what you thought was requested.

Code should be in 'straight' C using the compiler of your choice (cc or gcc) on nias.

Always use nice to execute your test programs at lower priority to ensure they do not inconvenience other users if they go 'haywire'. e.g.:
 
   >nice a.out