Objectives

There are four objectives to this assignment:

To familiarize yourself with the Linux programming environment.

To develop your defensive programming skills in Java.

To gain exposure to the necessary functionality in shells.

To learn how processes are handled (i.e., starting and waiting for their termination).

Overview

In this assignment, you will implement a command line interpreter or shell. The shell should operate in this basic way: when you type in a command (in response to its prompt), the shell creates a child process that executes the command you entered and then prompts for more user input when it has finished.

The shells you implement will be similar to, but much simpler than, the one you run every day in Linux/Unix. You can find out which shell you are running by typing echo $SHELL at a prompt. You may then wish to look at the man pages for sh or the shell you are running (more likely tcsh or bash) to learn more about all of the functionality that can be present. For this project, you do not need to implement much functionality; but you will need to be able to handle running multiple commands simultaneously.

Your shell will be interactive . In interactive mode, you will display a login prompt for the user. it should prompt user for username and password. Password is always cs340 (lower case). If sucessfull login, you will display a prompt (prompt = users login id, for example if I login and type username the pormpt will be upvi1234). Your shell stops accepting new commands when it sees the quit command on a line or the user types 'Ctrl-D'). The shell should then exit after all running processes have terminated.

The shell should not print the next prompt or take more input until all of the commands have finished executing. For example, the following lines are all valid and have reasonable commands specified:

prompt> prompt> ls prompt> /bin/ls prompt> ls -l prompt> ls -l ; cat file prompt> ls -l ; cat file ; grep foo file2

For example, on the last line, the commands ls -l , cat file and grep foo file2 should all be running at the same time; as a result, you may see that their output is intermixed.

To exit the shell, the user can type quit. This should just exit the shell and be done with it. Note that quit is a built-in shell command; it is not to be executed like other programs the user types in. If the "quit" command is on the same line with other commands, you should ensure that the other commands execute (and finish) before you exit your shell.

These are all valid examples for quitting the shell. prompt> quit prompt> quit ; cat file prompt> cat file ; quit

Program Specifications

Your program must be invoked exactly as follows: java QCShell

Defensive programming is an important concept in operating systems: an OS can't simply fail when it encounters an error; it must check all parameters before it trusts them. In general, there should be no circumstances in which your java program will core dump, hang indefinately, or prematurely terminate. Therefore, your program must respond to all input in a reasonable manner; by "reasonable", we mean print an understandable error message and either continue processing or exit, depending upon the situation.

You should consider the following situations as errors; in each case, your shell should print a message (to System.err.println()) and exit gracefully:

An incorrect number of command line arguments to your shell program.

The batch file does not exist or cannot be opened.

For the following situation, you should print a message to the user (System.err.println()) and continue processing:

A command does not exist or cannot be executed.

Optionally, to make coding your shell easier, you may print an error message and continue processing in the following situation:

A very long command line (for this project, over 512 characters including the ' ').

Your shell should also be able to handle the following scenarios, which are not errors (i.e., your shell should not print an error message):

An empty command line.

Extra white spaces within a command line.

In no case, should any input or any command line format cause your shell program to crash or to exit prematurely. You should think carefully about how you want to handle oddly formatted command lines (e.g., lines with no commands between a ;). In these cases, you may choose to print a warning message and/or execute some subset of the commands. However, in all cases, your shell should continue to execute!

prompt> ; cat file ; grep foo file2 prompt> cat file ; ; grep foo file2 prompt> cat file ; ls -l ; prompt> cat file ;;;; ls -l prompt> ;; ls -l prompt> ;

Hints

Your shell is basically a loop: it repeatedly prints a prompt, parses the input, executes the command specified on that line of input, and waits for the command to finish, if it is in the foreground. This is repeated until the user types "quit" or ends their input.

You should structure your shell such that it creates a new process for each new command. There are two advantages of creating a new process. First, it protects the main shell process from any errors that occur in the new command. Second, it allows easy concurrency; that is, multiple commands can be started and allowed to execute simultaneously (i.e., in parallel style).

Miscellaneous Hints

Remember to get the basic functionality of your shell working before worrying about all of the error conditions and end cases. For example, first focus on a single command running (probably first a command with no arguments, such as "ls"). Next, try working on multiple jobs separated with the ; character. Finally, make sure that you are correctly handling all of the cases where there is miscellaneous white space around commands or missing commands.

Beat up your own code! You are the best (and in this case, the only) tester of this code. Throw lots of junk at it and make sure the shell behaves well. Good code comes through testing -- you must run all sorts of different tests to make sure things work as desired. Don't be gentle -- other users certainly won't be. Break it now so we don't have to break it later.

Keep versions of your code. More advanced programmers will use a source control system such as CVS. Minimally, when you get a piece of functionality working, make a copy of your .java file (perhaps a subdirectory with a version number, such as v1, v2, etc.). By keeping older, working versions around, you can comfortably work on adding new functionality, safe in the knowledge you can always go back to an older, working version if need be.

Grading

For this project, you need to hand in two distinct items:

Your source code (no object files or executables, please!)

A README file with some basic documentation about your code

Under your $HOME directory, create a subdirectory: project1 (case sensitive). Copy all of your .java source files into this directory. Do not submit any other files. MAKE SURE TO GIVE ME PROPER PERIMISSIONS. On the deadline - I will copy all the files from your respective directory to mine for grading Remember: No late projects will be accepted!

Finally, I would like to see a file called README describing your code. This file should have contain the following four sections:

Your name and login information

Design overview: A few paragraphs describing the overall structure of your code and any important structures.

Complete specification: Describe how you handled any ambiguities in the specification. For example, for this project, explain how your shell will handle lines that have no commands between semi-colons.

Known bugs or problems: A list of any features that you did not implement or that you know are not working correctly

Due to the simplificity of this project, the documentation for this project is fairly minimal. It may be more extensive for future projects. The majority of your grade for this assignment will depend upon how well your implementation works and a smaller portion will be given for documentation and style. We will run your program on a suite of about 20 test cases, some of which will exercise your programs ability to correctly execute commands and some of which will test your programs ability to catch error conditions. Be sure that you thoroughly exercise your program's capabilities on a wide range of test suites, so that you will not be unpleasantly surprised when we run our tests.

Even though you will not be heavily graded on style for this assignment, you should still follow all the principles of software engineering you learned in CSCI 111, 211, 212 313, and elsewhere, such as top-down design, good indentation, meaningful variable names, modularity, and helpful comments. Don't be sloppy! You should be following these principles for your own benefit.

Finally, while you can develop your code on any system that you want, make sure that your code runs correctly on a machine that runs the Linux operating system. Specifically, since libraries and environments sometimes vary in small and large ways across systems, you should verify your code on the linux machines - venus. This machine is where your projects will be tested.

Java Runtime

public class ProcessDemo { public static void main(String[] args) throws Exception { Runtime r=Runtime.getRuntime(); System.out.println("No of Processor: "+ r.availableProcessors()); System.out.println("Total memory: "+r.totalMemory()); System.out.println("Free memory: "+r.freeMemory()); System.out.println("Memory occupied: "+ (r.totalMemory()-r.freeMemory())); for(int i=0;i<=10000;i++){ new Object(); } r.gc(); System.out.println("::Memory status::"); System.out.println("Total memory: "+r.totalMemory()); System.out.println("Free memory: "+r.freeMemory()); System.out.println("Memory occupied: "+ (r.totalMemory()-r.freeMemory())); } }

Java Process

import java.util.concurrent.TimeUnit; public class ProcessDemo { public static void main(String[] args) throws Exception { Runtime r = Runtime.getRuntime(); Process p = r.exec("firefox"); p.waitFor(10, TimeUnit.SECONDS); p.destroy(); } }