Projeect: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.
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]โ[m@k:~/p]$ ./hello
Hello world!
[๐]โ[2]โ[m@k:~/p]$ ls /usr
bin include lib local sbin share src
[๐]โ[3]โ[m@k:~/p]$ echo hello there! hello there!
[๐]โ[4]โ[m@k:~/p]$ ./blah
crash: no such file or directory: ./b
[๐คฎ]โ[5]โ[m@k:~/p]$ cd /this/does/not/exist chdir: no such file or
directory: /this/does/not/exist
[๐คฎ]โ[6]โ[m@k:~/p]$
Prompt
The shell prompt displays some helpful information. At a minimum, you must include:
4/2/2021
2/8
Command number (starting from 1)
User name and host name: (username@(hostname followed by :
The current working directory
Process exit status
In the example above, these are separated by dashes and brackets to make it a little easier to
read. The process exit status is shown as an emoji: a smiling face for success (exit code ) and a
sick face for failure (any nonzero exit code or failure to execute the child process). For this
assignment, you are allowed to invent your own prompt format as long as it has the elements
listed above. You can use colors, unicode characters, etc. if you’d like. For instance, some shells
highlight the next command in red text after a nonzero exit code.
You will format the current working directory as follows: if the CWD is the user’s home directory,
then the entire path is replaced with ~ . Subdirectories under the home directory are prefixed
with ~ ; if I am in /home/m/test , the prompt will show ~/test . Here’s a test to make sure
you’ve handled ~ correctly:
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.
[๐]โ[6]โ[m@k:~]$ whoami
m
[๐]โ[7]โ[m@k:~]$ cd P
# Create a directory with our full home directory in its path:
# **Must use the username outputted above from whoami)**
# Note that the FULL path is shown here (no ~):
[๐]โ[10]โ[m@k:/tmp/home/m/test]$ pwd
/tmp/home/m/test
cat <ls /
echo "hi"
exit
EOM
4/2/2021
3/8
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
#include
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:
cd to change the CWD. cd without arguments should return to the user’s home directory.
# (comments): strings prefixed with # will be ignored by the shell
history , which prints the last 100 commands entered with their command numbers
# Which outputs (note how the prompt is not displayed):
bin boot dev etc home lib lost+found mnt opt proc root run s
hi
# Another option (assuming commands.txt contains shell commands):
./crash < commands.txt
(commands are executed line by line)
4/2/2021
4/8
! (history execution): entering !39 will re-run command number 39, and !! re-runs the
last command that was entered. !ls re-runs the last command that starts with ‘ls.’ Note
that command numbers are NOT the same as the array positions; e.g., you may have 100
history elements, with command numbers 600 – 699.
jobs to list currently-running background jobs.
exit to exit the shell.
Signal Handling
Your shell should gracefully handle the user pressing Ctrl+C:
[๐]โ[11]โ[m@k:~]$ hi there oh wait nevermind^C
[๐]โ[11]โ[m@k:~]$ ^C
[๐]โ[11]โ[m@k:~]$ ^C
[๐]โ[11]โ[m@k:~]$ sleep 100
^C
[๐คฎ]โ[12]โ[m@k:~]$ sleep 5
The most important aspect of this is making sure ^C doesn’t terminate your shell. To make the
output look like the example above, in your signal handler you can (1) print a newline character, (2)
print the prompt only if no command is currently executing, and (3) fflush(stdout) .
History
Here’s a demonstration of the history command:
[๐]โ[142]โ[m@k:~]$ 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
4/2/2021
5/8
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).
I/O Redirection
Your shell must support file input/output redirection:
# Create/overwrite 'my_file.txt' and redirect the output of echo there:
[๐]โ[14]โ[m@k:~]$ echo "hello world!" > my_file.txt
[๐]โ[15]โ[m@k:~]$ cat my_file.txt
hello world!
# Append text with '>>':
[๐]โ[16]โ[m@k:~]$ echo "hello world!" >> my_file.txt
[๐]โ[17]โ[m@k:~]$ cat my_file.txt
hello world!
hello world!
# Let's sort the /etc/passwd file via input redirection:
[๐]โ[18]โ[m@k:~]$ sort < /etc/passwd > sorted_pwd.txt
# Order of < and > don't matter:
[๐]โ[19]โ[m@k:~]$ sort > sorted_pwd.txt < /etc/passwd
# Here's input redirection by itself (not redirecting to a file):
[๐]โ[20]โ[m@k:~]$ sort < sorted_pwd.txt
(sorted contents shown) Use dup2 to achieve this; right before the newly-created child process calls execvp , you will
open the appropriate files and set up redirection with dup2 .
Background Jobs
If a command ends in & , then it should run in the background. In other words, don’t wait for the
command to finish before prompting for the next command. If you enter jobs , your shell should
print out a list of currently-running backgrounded processes (use the original command line as it
was entered, including the & character). The status of background jobs is not shown in the
prompt.
4/2/2021
6/8
To implement this, you will need:
A signal handler for SIGCHLD . This signal is sent to a process any time one of its children
exit.
A non-blocking call to waitpid in your signal handler. Pass in pid = -1 and options
= WNOHANG .
This tells your signal handler the PID of the child process that exited. If the PID is in
your jobs list, then it can be removed.
The difference between a background job and a regular job is simply whether or not a blocking
call to waitpid() is performed. If you do a standard waitpid() with options = 0 , then
the job will run in the foreground and the shell won’t prompt for a new command until the child
finishes (the usual case). Otherwise, the process will run and the shell will prompt for the next
command without waiting.
NOTE: your shell prompt output may print in the wrong place when using background jobs. This is
completely normal.
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.
Hints
Here’s some hints to guide your implementation:
execvp will use the PATH environment variable (already set up by your default shell) to find
executable programs. You don’t need to worry about setting up the PATH yourself.
Check out the getlogin , gethostname , and getpwuid functions for constructing
your prompt.
Don’t use getwd to determine the CWD – it is deprecated on Linux. Use getcwd instead.
For the cd command, use the chdir syscall.
To replace the user home directory with ~ , some creative manipulation of character arrays
and pointer arithmetic can save you a bit of work.
4/2/2021
7/8
Testing Your Code
Check your code against the provided test cases. You should make sure your code runs on your
Arch Linux VM. We’ll have interactive grading for projects, where you will demonstrate program
functionality and walk through your logic.
Submission: submit via GitHub by checking in your code before the project deadline.
Grading
~20 pts - Passing the test cases (coming soon!)
4 pts - Code review:
Prompt, UI, and general interactive functionality. We’ll run your shell to test this with a
few commands.
Code quality and stylistic consistency
Functions, structs, etc. must have documentation in Doxygen format (similar to
Javadoc). Describe inputs, outputs, and the purpose of each function. NOTE: this is
included in the test cases, but we will also look through your documentation.
No dead, leftover, or unnecessary code.
You must include a README.md file that describes your program, how it works, how to
build it, and any other relevant details. You’ll be happy you did this later if/when your
revisit the codebase. Here is an example README.md file.
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.
Changelog