BACKGROUND: A shell provides a command-line interface for users. It interprets user commands and executes them. Some shells provide simple scripting terms, such as if or while, and allow users to make a program that facilitates their computing environment. Under the hood, a shell is just another user program as you know from Minor2 assignment. The file /bin/bash is an executable program file for the bash shell. The only thing special about your login shell is that it is listed in your login record so that /bin/login (i.e., the program that prompts you for your password) knows what program to start when you log in. If you run “cat /etc/passwd”, you will see the login records of the machine.
PROGRAM DESCRIPTION
GROUP COLLABORATIVE PORTION: In this assignment, you will implement the shell “engine” as the group component, where all members are responsible for the following functionality.
A Command-Line Interpreter, or Shell
Your shell should read the line from standard input (i.e., interactive mode) or a file (i.e., batch mode), parse the line with command and arguments, execute the command with arguments, and then prompt for more input (i.e., the shell prompt) when it has finished. This is what Minor 2 program should do with addition of batch processing which means just reading a batch line by line and calling the same interpretation logic.
- Batch Mode
In batch mode, your shell is started by specifying a batch file on its command line. The batch file contains the list of commands that should be executed. In batch mode, you should not display a prompt, but you should echo each line you read from the batch file back to the user before executing it. After a batch is finished the shell will exit.
- Interactive Mode
No parameters specified on command line when the shell is started. In this mode, you will display a prompt (any string of your choice) and the user of the shell will type in a command at the prompt.
You will need to use the fork() and exec() family of system calls. You may not use the system() system call as it simply invokes the system’s /bin/bash shell to do all of the work. You may assume that arguments are separated by whitespace. You do not have to deal with special characters such as ‘, “, , etc. You may assume that the command-line a user types is no longer than 512 bytes (including the ‘n’), but you should not assume that there is any restriction on the number of arguments to a given command.
INDIVIDUAL PORTIONS
Build-in Commands: Every shell needs to support a number of built-in commands, which are functions in the shell itself, not external programs. Shells directly make system calls to execute built-in commands, instead of forking a child process to handle them.
In this assignment, each member of the group will implement one of the following section and commit in GitLab the code that supports those commands:
- Add a new built-in alias command that allows you to define a shortcut for commands by essentially defining a new command that substitutes a given string for some command, perhaps with various flags/options. The syntax is as follows: alias alias_name=’command’. For example, you can define an alias with alias ll=’ls –al’, so that the user can then enter ll at the prompt to execute the ls -al command. Specifying alias with no arguments should display a list of all existing aliases. You may remove a single alias with the command alias -r alias_name or all defined aliases with alias -c.
- Add a new built-in exit command that exits from your shell with the exit() system call. Also add support for signal handling and terminal control (Ctrl-C, Ctrl-Z). You do not want those signals to terminate your shell. Instead you need to handle them and terminate processes that your shell started if any. Be aware that forked processes will inherit the signal handlers of the original process.
- Add a new built-in path command that allows users to show the current pathname list. The initial value of path within your shell will be the pathname list contained in the PATH environment variable. path + ./dir appends the ./dir to the path variable. You may assume that only one pathname is added at a time. You will need to add it to the “real” PATH environment variable for executables in the path to work correctly. path – ./dir removes the pathname from the path variable. You may assume that only one pathname is removed at a time. Also, you need to restore your PATH environment variable to its original state when the user exits your shell.
- Add a new built-in history command that lists your shell history of previous commands. It is up to you to select what number of prior commands to keep in history. history –c command should clear your history list. history N, where N is number, displays your prior N-th command starting with the last one. history N -e executes your prior N-th command.
OPTIONAL assignments for extra credits:
- Extend your shell with I/O redirection: <, >, >> (+20%).
- Extend your shell with pipelining | (+20%).
DEFENSIVE PROGRAMMING (GROUP COLLABORATIVE EFFORT): Check the return values of all system calls utilizing system resources. Do not blindly assume all requests for memory will succeed and that all writes to a file will occur correctly. Your code should handle errors properly. In general, there should be no circumstances in which your C program will core dump, hang indefinitely, or prematurely terminate. Therefore, your program must respond to all input by printing a meaningful error message and either continue processing or exit, depending upon the situation. Many questions about functions and system behavior can be found in the manual pages. You should handle the following situations:
- An incorrect number of command line arguments to your shell program;
- The batch file does not exist or cannot be opened.
- A command does not exist or cannot be executed.
- A very long command line (over 512 characters including the ‘n’).
REQUIREMENTS: Your code must be written in C.
GRADING: Your C program file(s), README, and makefile shall be committed to our GitLab environment as follows:
- Your C program file(s). Your code should be well documented in terms of comments. For example, good comments in general consist of a header (with your name, course section, date, and brief description), comments for each variable, and commented blocks of code.
- A README file with some basic documentation about your code. This file should contain the following four components:
Your name(s);
Organization of the Project. Since there are multiple components in this project, you will describe how the work was organized and managed, including which team members were responsible for what components – there are lots of ways to do this, so your team needs to come up with the best way that works based on your team’s strengths. Note that this may be used in assessment of grades for this project.
Design Overview: A few paragraphs describing the overall structure of your code and any important structures.
Known Bugs or Problems: A list of any features that you did not implement or that you know are not working correctly.
- A Makefile for compiling your source code, including a clean directive.
- Your program will be graded based largely on whether it works correctly on the CSE machines.
