Programming Assignment #2

For assignment #2 we will be writing a more complete command line interpreter. It will support switches (also called options), expanded versions of the commands you wrote in assignment #1, some "shell built-ins," and will go about creating processes more 'realistically' than the use of system() or using open to control a process.

Like with assignment #1, your command line interpreter should have a hard-coded search path where it will look for the executable files to run. Again, for emphasis; your command line interpreter must have a hard coded search path. In addition, we should be able to add an executable file in the directory which corresponds to your search path, and be able to execute it from your command line interface without any additional changes. You will be eligible for bonus marks if we can actually add any executable file written in any language.

Switches (also called Options)

Your new command line interpreter should be able to accept command line switches (also called command line options). Individually, each of the scripts should be able to accept particular switches, specified in their descriptions below.

The command line interpreter should accept switches syntactically in the same way the way the Linux command line does; switches (also called options) are denoted with dashes '-'. The following would be a way of executing the DIR command with the 'L' switch:

DIR -L

We should be able to specify any number of switches concurrently:

FIND -P -C word file.txt
FIND -PC word file.txt #means the same thing

Your individual commands, when executed independently of your command line interpreter, will also be able to accept the same options:

perl yourScript.pl -L

Take note that options (also called switches) are case sensitive.

Syntactically, you should assume that all switches will appear before any arguments.

Spawning Processes

When you type a command into a command line interpreter, it spawns a new process to execute the program which corresponds to that command. In the command line interpreters you may have written for assignment #1, this is being taken care of internally; the system() function (or filehandles and pipes, if you used those) cleanly spawns processes for you if necessary. For this assignment, you will have to change your command line interpreter so it uses Perl's fork and exec functions to spawn child processes, as described on slides 41 and 42 in your process notes from week 2 on the web site. We have not seen fork and exec in tutorial, and we may not get to them; you will have to research them independently.

Your command line interpreter should not support piped input.

Commands

The following are executable commands which you have to write and submit with your command line interface. We should be able to execute them using your command line interface.

All of these scripts should display help and 'usage' messages when the -h switch is specified.

The DIR Command

Your command line interpreter should be able to execute a command similar to the Ms-Dos tool DIR which you will implement in Perl and include in your assignment submission. It should accept the following switches (options):

• h: If the 'h' option is specified, the script should do nothing but give a help message, and an explination of its usage.
• L: If the 'L' switch is specified, the output should include the following information about each file: its iNode number, file type, mode/permissions (presented in a format similar to ls -l), the number of hard links to that file, the file's owner, the file's group, the file's size, and the date the file was last modified. All of this should be in the same format provided by using ls -il on the Linux command line.

The FIND Command

Your command line interpreter should be able to execute a command similar to the Ms-Dos tool FIND which you will implement in Perl and include in your assignment submission. It should accept the following switches (options):

• h: If the 'h' option is specified, the script should do nothing but give a help message, and an explination of its usage.
• C: This is an existing switch for the Ms-Dos FIND command. You should be able to find information about it online, or by consulting the HELP entries on an Ms-Dos command line.
• N: This is an existing switch for the Ms-Dos FIND command. You should be able to find information about it online, or by consulting the HELP entries on an Ms-Dos command line.
• P: Using this switch, the substring for which FIND searches for within the file will be treated as a Perl regular expression rather than a substring.

While your command line interpreter should not support piping input/output, your implementation of FIND should nonetheless support piped input if no filename is provided:

cat myFile.txt | perl yourFindScript substring
	# this should work the same as…
	# perl yourFindScript substring myFile.txt

The CLS Command

Your command line interpreter should be able to execute a command similar to the Ms-Dos tool CLS which you will implement in Perl and include in your assignment submission. It should accept the following switches (options):

• h: If the 'h' option is specified, the script should not execute and should give a help message, and an explination of its usage.

The TYPE Command

Your command line interpreter should be able to execute a command similar to the Ms-Dos tool TYPE which you will implement in Perl and include in your assignment submission.
While your command line interpreter need not support piping input/output, your implementation of TYPE should nonetheless support piped input if no filename is provided:

cat myFile.txt | perl yourTypeScript
	# this should work the same as…
	# perl yourTypeScript myFile.txt

To get marks for piped input your implementation should either re-assign/overload the STDIN filehandle, or alias the STDIN filehandle. You should not have the same code written twice using different filehandles.

It should also accept the following switches (options):

• h: If the 'h' option is specified, the script should do nothing but give a help message, and an explination of its usage.

The STAT Command

Your assignment should include an implementation of the STAT tool, written in Perl, which functions similarly to the Linux tool of the same name. You cannot delegate the functionality of this script to the Linux command line with system("stat"), and you cannot use file tests to determine a file's information; you are required to interpret the data returned by Perl's lstat function. Your implementation of STAT should accept the following switches (options):

• h: If the 'h' option is specified, the script should do nothing but give a help message, and an explination of its usage.

Notes and Implementation Constraints

Your Commands and Interpreter Must Be Separate and Modular

Your scripts should not rely on the existence of your command line interpreter in any way. We should be able to execute them normally without the command line interpreter; We should be able to even delete the command line interpreter script and all your commands will execute normally.

Likewise, your command line interpreter should not rely on the existence of your commands; if We delete one of your command scripts, it should simply no longer be available from the command line.

Subroutine to 'Parse' Input

When your command line interpreter reads in a line from STDIN it should pass the input to a subroutine which parses the input, and returns a hash with the following key/value pairs:

Key	Value
Command	The name of the command to be executed.
Switches	A hash, containing all switches specified as keys.
Arguments	An array of arguments.

Help option

All your scripts both commands and command line interpreter – must be able to accept an option 'h' which causes them to display a help / usage message.

How Does a Command Line Interpreter Work?

Bear in mind the following when writing your script:

• Keyboard input is passed to the command line interpreter, which processes it and executes commands by looking for an executable of the same name in a search path.
  • To see what the search path is on your Linux machine, type 'echo $PATH' in on the command line.
  • To see what the search path is on your Windows machine, type 'path' in on the command line.
• The executable file runs, making calls to the system to perform a particular task.

So let's take an example, using the ps command on a Linux machine.

• * When you type in 'ps' on a command line interpreter, it will first look in the your search paths. There be multiple search paths; note that when you type 'echo $PATH' on a Linux machine, there may be several directories listed, separated by colon (':') characters. So the command line interpreter will look for an executable 'ps' in the following directories:
  • /usr/local/bin
  • /usr/bin
  • /bin
• The command line interpreter finds an executable file '/bin/ps' which it then runs.
  • What if there is an executable file 'ps' in more than one of those directories? The command line interpreter executes the first one it finds. To know which 'ps' would be executed by the command line interpreter, type in 'which ps'.
• The ps executable accesses system resources to perform its task – displaying a list of processes.
• You could use the ps tool on the command line 'the long way' by typing in /bin/ps on the command line.

Your command line interpreter will have its own hard-coded search path; the name of a directory which will contain your executable commands, written in Perl. There will be extra marks if we can add my own executable file to the search path – written in any language – and be able to run it from your command line interpreter.

Bonus Marks: Shell Built-Ins

For bonus marks, you can define the following shell built-ins as a subroutines. When a user types in the appropriate command, the subroutine should be executed, with the arguments as parameters. The bonus marks will only be given if:

• The subroutine is called using a reference.
• The implementation is not vulnerable to attack; it only allows for these four functions could possibly be executed.
• In your 'readme.txt' you provide an explanation – in your own words – of what the difference is between a "shell built-in" and an "executable command" or "command line tool."

Built-In	Purpose
CHDIR	Changes the current working directory. You will have to research what arguments it accepts.
WHICH	This will function similarly to the Linux tool 'which'. This will display the full path to a an executable file which would be executed were you to input a command. You should research what arguments it takes.
PATH	Like the Ms-Dos command of the same name, this should display the command line interpreter's search path.
EXIT	A means by which to exit the command line interpreter cleanly.

What to Submit

You should submit an archived (zipped) file containing a folder full of your executable commands, the script which serves as your command line interpreter (if you wrote one) and one 'readme.txt' file explaining each of your your scripts. Your 'readme.txt' should explain how to run your script without using the Perl interpreter, as well as how to change the search path so we can test your command line interpreter.

If you face any particular challenges, feel the assignment is ambiguous and have to make assumptions, or are uncertain of one of your solutions, explain this in your readme.txt file to potentially get partial marks.

You've seen everything you'll need for this assignment in the tutorials unless it is specified otherwise above. Do not go looking for exra Perl modules to use! Students lost marks for using non-standard Perl modules they didn't understand last assignment.

Comment your code well, or you will be marked poorly.

Marking Scheme

1. Theory (30%)
   1. Demonstrate understanding of your Command Line Interpertor and its scripts (readme, comments and usage) (10%)
   2. Demonstrate knowledge of processes (Perl's fork and exec functions) (5%)
   3. Demonstrate knowledge of iNode data (Perl's lstat function) (10%)
   4. Demonstrate knowledge of Perl (5%)
2. Coding (70%)
   1. DIR (10%)
      1. -h option
      2. -L option
         1. iNode
         2. File Type
         3. Permissions
         4. # of hard links
         5. File Owner
         6. File Group
         7. Size
         8. Date Modified
   2. FIND (5%)
      1. -h option
      2. Piping (overloading or aliasing STDIN)
   3. CLS (5%)
      1. -h option
   4. TYPE (5%)
      1. -h option
      2. Piping (overloading or aliasing STDIN)
   5. STAT (20%)
      1. -h option
         1. iNode
         2. File Type
         3. Permissions
         4. # of hard links
         5. File Owner
         6. File Group
         7. Size
         8. Date Accessed
         9. Date Modified
         10. Date Changed
   6. Command Line Interpretor (25%)
      1. -h option
      2. Subroutine to parse the input which returns a multi-dimensional hash
      3. Use of fork and exec to spawn child processes
      4. Clarity of algorithm design