CST8204 Lab Assignment 4: MOSH (My Own Shell)
The company you work for needs to have a simplified shell for several POSIX-compliant systems for some staff who are are not familiar with Linux or Unix commands. You are assigned to this project and are provided with the following basic requirements for the 14 commands that have been determined to be the minimum necessary.
Full form |
Abbrev |
Description |
|
clear |
c |
clear the screen |
|
delete <fname> |
d |
delete the file after user confirmation |
|
exit |
x |
terminate mosh after user confirmation |
|
file [long] [<names>] |
f |
show directory information for the named files or directories, or for the current directory if no name is given, in full form for long (like ls -l) |
|
goto <dname> |
-- |
change into the directory named |
|
help
[<command name |
h |
display brief usage information for the command or its abbreviation; or short general help if no argument is given |
|
list <fname> |
l |
list the contents of the text file |
|
make <dname> |
m |
make a new directory in the current directory |
|
new
<fname> [from |
n |
create a new text file unless it already exists, reading input from stdin or "from fname" until the end of file condition (^D or equivalent from fname) is detected |
|
prompt <prompt text> |
p |
Set a new prompt string (default is "mosh> ") |
|
remove <dname> |
r |
remove the named directory only if it is empty, and after user confirmation |
|
run
<[path/]program |
-- |
execute any arbitrary program, passing along all its arguments, with a path if necessary |
|
select <regex> from <fname> [and [not] <regex> ...] |
s |
select lines from the text file fname using regex (regular expressions); see example and the required test below |
|
where |
w |
display the name of the current directory |
A <dname> is a Linux directory and an <fname> is a Linux text file (mosh does not directly support non-text files). Either can be prefixed with an optional path using forward slashes as usual. You must support the '~' and the '.', and '..' relative paths as well as absolute paths, but filespec wild cards (file globbing) are not required. All error messages will be sent to stderr. Items in [square brackets] are optional.
The commands where, help, file, list, and select may include "into <fname>" to redirect the command's stdout to the named file, which is to be created if necessary or replaced if it already exists. The keyword into may be abbreviated as in or to even if the command itself is in its unabbreviated form.
The select command will behave like grep, or a series of grep statements. That is, as an example, "select a from ff and not b and c into oo" will act as though the command sequence "grep "a" ff | grep -v "b" | grep "c" > oo" had been given to the bash shell.
You will implement mosh in a C program by forking child processes as needed to execute suitable shell commands to perform the required action when you can. You may not use the system functions system() or popen(); you are to use fork() and one or more forms of exec() to execute shell-level commands, except for any built-in or special commands that must execute in the parent process (e.g., exit and goto; include explanations in your comments). You may also not use the strtok() function (see safer functions like strchr() and strpbrk() instead). Resist the urge to write everything yourself, and use standard Unix commands like ls, cat, mkdir, grep, and so on, whenever possible. You may not write and execute shell scripts.
You must support the abbreviated versions of the commands above in the form shown here. All command elements and their abbreviations must be defined in the form of tables (that is, not hard-coded into your logic), using structures, character arrays, and/or pointers for parsing so that the commands and their abbreviations may be translated to another language, revised, renamed, or replaced by another programmer with relative ease. These can either be hard-coded as data or read in and initialized at start-up (see BONUS).
BONUS: You may choose to read in a complete command table and all text messages at mosh initialisation, for a 10% bonus if done well.
You must hand in all the usual assignment submission material, including:
Program listings (including at least 3 functions, each in its own file) for mosh, with useful comments; your analysis document; Test Plan; any #include files you write; and your Makefile (make must be used); and any important text files you use (such as the help text).
The commented script output from at least one session with mosh, in which you demonstrate every command at least once correctly, in both full and short forms. You must include several examples of erroneous input to mosh to demonstrate that your error checking is as complete as possible. This test run is to adhere strictly to your Test Plan.
Be sure to show somewhere the content of the files used for your testing, the ls information for them as necessary, and the test directory structure(s) involved.
The output ought to be edited lightly for legibility, including a designation to coordinate these test results with your formal Test Plan, and to remove the middle parts of long files or file lists (show where material has been omitted by inserting a line like "..." or "[snip]") in its place).
You must show that this select command produces the correct output for the text file given below by also running the equivalent grep commands and comparing both output files with diff -s or cmp:
select
"^apple" from select-input and not "banana" and
"cake$"
into select-output
apple pie and banana cake
banana cream pie and applesauce cake
apple pie with cheese
cake donuts and apple pudding
apple pie or carrot cake
banana cream pie and applesauce cake
Your end user documentation for mosh, in final printed form perhaps only somewhat similar in style to a man page, ready to be duplicated and handed out to users. It should not exceed 1 or 2 pages of standard letter-size paper. It must be capable of training a new user of mosh in the appropriate use of all its capabilities. It would be useful for analysis and design to write this document first, even before your PDL.