Shell Program

Shell Program

pages 67 - 82 in Kernel Projects for Linux by G. Nutt.

Details: Support for background execution, command line operators and input/output redirection Due date: Thursday 4/22/2004 by 22:00 (10:00pm).

Description of tweak, implementation details, and examples

• Your shell should be able to support command line input with the following operators:
  
  • && (logical AND)
    • command1 && command2
      
      command2 is executed if, and only if, command1 returns an exit status of zero.
  • || (logical OR)
    • command1 || command2
      
      command2 is executed if, and only if, command1 returns a non-zero exit status.
      
  • ; (semicolumn)
    • command1 ; command2
      
      commands separated by a ';' are executed sequentially; the shell waits for each command to terminate in turn.
      
  • & (process backgrounding)
    • command1 &
      
      If a command is terminated by the control operator `&' , the shell executes the command asynchronously in a subshell. This is known as executing the command in the background . The shell does not wait for the command to finish, and the return status is 0 (true).
      
• Input/Output redirection: Your shell should be able to use files as input or output for commands. The redirection symbols "<" and ">" should be used in order to redirect the input and output of a command respectively. For example:

  sort < test.txt

  This command line will run the "sort" command and use the contents of the file "test.txt" as its input (instead of the standard input, which is usually the keyboard).

  ls > files.txt

  This command line will run the "ls" command and use the file "files.txt" to write its output (instead of the standard output, which is by default the terminal).

   

In addition to implementing the two previous features, you should also support their combinations. This means that your shell should be able to execute complex commands including both I/O redirection and command line operators.

sort < test.txt &

command1 && command2 > output.txt

Note that I/O redirection is always associated with the command it follows and NOT with the whole command line.

You must NOT implement any "extra" features! (like history, pipes etc).

The rest of the project should be implemented with the bash shell in mind. For example, whatever ls -l && sort does in bash, it should do that same thing in your shell.

Only execv() is allowed when executing a command (for instance, you may NOT use execvp()). Also, the access() system call should be used to check if a possible path for a command is valid.

You should consider spaces or tabs to be white space, and you should strip extra whitespace from between words. (i.e. ls -l should do the exact same thing as ls     -l)

Your shell must also implement two primitives: cd and exit. There is no command called cd, it's implemented inside the shell (use chdir()). cd by itself should return to the user's home directory.

Your shell should be able to handle command line input with the following grammar :

• command_line -> ε
• command_line -> command
• command_line -> command (whitespace)+ &
• command -> (whitespace)* program
• command -> (whitespace)* program (whitespace)+ symbol (whitespace)+ command
• symbol -> ||
• symbol -> &&
• symbol -> ;
• program -> path program_name (argument)*
• program -> path program_name (argument)* > file
• program -> path program_name (argument)* < file
• program -> path program_name (argument)* > file < file
• program -> path program_name (argument)* < file > file
• path -> ε
• path -> ./ (dir/)*
• path -> / (dir/)*
• argument -> ε
• argument -> (whitespace)+ argument

In the above grammar "ε" means "empty string", (A)* means "A repeated 0 or more times", and (A)+ means "at least one A".

Your prompt should be exactly "# ", as in the examples above and below.

You should open a file for output redirection only if the command is valid and is going to be executed. When you open a file for output redirection, the file should be overwritten (data should not be appended to the file - just like bash).

Your shell should use the current value of PATH to search for commands.

Your shell should handle certain error cases and produce the appropriate error messages. Some suggested error messages are the following:

• "No such file or directory" - when a file doesn't exist e.g. when it supposed to be used for stdin redirection
• "Permission denied" - open fails for a redirection
• "Syntax error" - when the command line is not recognized as legitimate input
• "Command not found" - when the user typed a command that is not found in the PATH

After starting your shell, users should be able to execute commands like:
# find /bin -name ls -print

# cd /etc

# ls && cal

# ls > test.txt

# sort < test.txt

# ls -l /bin || find /lib > test2.txt

# ls -l /bin ; ps -ef ; sort -nr < test2.txt

# find /lib > /tmp/find.txt &

Details on how to turn in Project #1 (+ test cases) will be posted the week before the project is due.

(From URL:  http://www.cs.ucla.edu/~pefstath/cs111/p1s04.htm)