Project 2: Command Line Shell

The outermost layer of the operating system is called the shell. In Unix-based systems, the shell is generally a command line interface. Most Linux distributions ship with bash as the default (there are several others: csh, ksh, sh, tcsh, zsh). In this project, we’ll be implementing a shell of our own.

You will need to come up with a name for your shell first. The only requirement is that the name ends in ‘sh’, which is tradition in the computing world. In the following examples, my shell is named crash (Cool Really Awesome Shell) because of its tendency to crash.

Here’s a project skeleton to get you started. You can download it to your VM with wget and extract it with the tar command.

The Basics

Upon startup, your shell will print its prompt and wait for user input. Your shell should be able to run commands in both the current directory and those in the PATH environment variable (run echo $PATH to see the directories in your PATH). The execvp system call will do most of this for you. To run a command in the current directory, you’ll need to prefix it with ./ as usual. If a command isn’t found, print an error message:

[🙂]─[1]─[mmalensek@deltron:~/P2-malensek]$ ./hello
Hello world!

[🙂]─[2]─[mmalensek@deltron:~/P2-malensek]$ ls /usr
bin  include  lib  local  sbin  share  src

[🙂]─[3]─[mmalensek@deltron:~/P2-malensek]$ echo hello there!
hello there!

[🙂]─[4]─[mmalensek@deltron:~/P2-malensek]$ ./blah
crash: no such file or directory: ./blah

[🤮]─[5]─[mmalensek@deltron:~/P2-malensek]$ cd /this/does/not/exist
chdir: no such file or directory: /this/does/not/exist

[🤮]─[6]─[mmalensek@deltron:~/P2-malensek]$

Prompt

The shell prompt displays some helpful information. Since this is your own custom shell, you get to design the prompt. The only requirement is that it should have at least four bits of information to help the user – what those are is totally up to you. In the example above, I have included:

There are certainly other bits of useful information you can include… It’s up to you!

Scripting

Your shell must support scripting mode to run the test cases. Scripting mode reads commands from standard input and executes them without showing the prompt.

cat <<EOM | ./crash
ls /
echo "hi"
exit
EOM

# Which outputs (note how the prompt is not displayed):
bin  boot  dev  etc  home  lib  lost+found  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
hi

# Another option (assuming commands.txt contains shell commands):
./crash < commands.txt
(commands are executed line by line)

You should check and make sure you can run a large script with your shell. Note that the script should not have to end in exit.

To support scripting mode, you will need to determine whether stdin is connected to a terminal or not. If it’s not, then disable the prompt and proceed as usual. Here’s some sample code that does this with isatty:

#include <stdio.h>
#include <unistd.h>

int main(void) {

    if (isatty(STDIN_FILENO)) {
        printf("stdin is a TTY; entering interactive mode\n");
    } else {
        printf("data piped in on stdin; entering script mode\n");
    }

    return 0;
}

Since the readline library we’re using for the shell UI is intended for interactive use, you will need to switch to a traditional input reading function such as getline when operating in scripting mode.

When implementing scripting mode, you will likely need to close stdin on the child process if your call to exec() fails. This prevents infinite loops.

Built-In Commands

Most shells have built-in commands, including cd and exit. Your shell must support:

Signal Handling

Make sure ^C doesn’t terminate your shell. You’ll need to handle SIGINT to do this.

History

Here’s a demonstration of the history command:

[🙂]─[142]─[mmalensek@deltron:~]$ history
  43 ls -l
  43 top
  44 echo "hi" # This prints out 'hi'

... (commands removed for brevity) ...

 140 ls /bin
 141 gcc -g crash.c
 142 history

In this demo, the user has entered 142 commands. Only the last 100 are kept, so the list starts at command 43. If the user enters a blank command, it should not be shown in the history or increment the command counter. Also note that the entire, original command line string is shown in the history – not a tokenized or modified string. You should store history commands exactly as they are entered (hint: use strdup to duplicate and store the command line string). The only exception to this rule is when the command is a history execution (bang) command, e.g., !42. In that case, determine the corresponding command line and place it in the history (this prevents loops).

Command Pipelines and Redirection

Your shell must support command pipelines and I/O redirection:

# Create/overwrite 'my_file.txt' and redirect the output of echo there:
[🙂]─[14]─[mmalensek@weenie-hut-jr:~]$ echo "hello world!" > my_file.txt
[🙂]─[15]─[mmalensek@weenie-hut-jr:~]$ cat my_file.txt
hello world!

# Append text with '>>':
[🙂]─[16]─[mmalensek@weenie-hut-jr:~]$ echo "hello world!" >> my_file.txt
[🙂]─[17]─[mmalensek@weenie-hut-jr:~]$ cat my_file.txt
hello world!
hello world!

# Pipe redirection:
[🙂]─[18]─[mmalensek@weenie-hut-jr:~]$ cat other_file.txt | sort
(sorted contents shown)

[🙂]─[19]─[mmalensek@weenie-hut-jr:~]$ seq 100000 | wc -l
10000

[🙂]─[20]─[mmalensek@weenie-hut-jr:~]$ cat /etc/passwd | sort > sorted_pwd.txt
(sorted contents written to 'sorted_pwd.txt')

# This is equivalent, but uses input redirection instead of cat:
[🙂]─[21]─[mmalensek@weenie-hut-jr:~]$ sort < /etc/passwd > sorted_pwd.txt

# This is equivalent as well. Order of < and > don't matter:
[🙂]─[22]─[mmalensek@weenie-hut-jr:~]$ sort > sorted_pwd.txt < /etc/passwd

# Here's input redirection by itself (not redirecting to a file):
[🙂]─[23]─[mmalensek@weenie-hut-jr:~]$ sort < sorted_pwd.txt
(sorted contents shown)

Use pipe and dup2 to achieve this. Your implementation should support arbitrary numbers of pipes, but you only need to support one file redirection per command line (i.e., a > or >> in the middle of a pipeline is not something you need to consider).

The readline library

We’re using the readline library to give our shell a basic “terminal UI.” Support for moving through the current command line with arrow keys, backspacing over portions of the command, and even basic file name autocompletion are all provided by the library. The details probably aren’t that important, but if you’re interested in learning more about readline its documentation is a good place to start.

Signature Feature

After you’re done implementing all the features above, you will need to choose to add one more feature to your shell. You can take inspiration from other shells, or come up with something completely new. It’s your choice – just make sure you run the idea by the instructor first. If you do not get your feature validated by the instructor, you cannot receive credit for this part of the assignment.

Documentation

You must include documentation for your shell, located in p2/README.md. The documentation must describe your program, how it works, and any other relevant details. You’ll be happy you did this later if/when your revisit the codebase.

Grading

Check your code into your projects repository under p2.

Restrictions: you may use any standard C library functionality. Other than readline, external libraries are not allowed unless permission is granted in advance (including the GNU history library). Your shell may not call another shell (e.g., running commands via the system function or executing bash, sh, etc.). Do not use strtok to tokenize input. Your code must compile and run on your VM set up with Arch Linux as described in class. Failure to follow these guidelines will will result in a grade of 0.

To receive 90% credit:

To receive 95% credit, implement:

To receive full credit for this project:

Code Review

Your grade will also include a code review. During the code review we will check:

You will also be asked to explain 1-3 parts of your implementation. You should be able to describe high-level design aspects and the challenges you faced implementing the features.