title: CS 537 Project 3 layout: default

CS537 Fall 2024, Project 3

Updates

TBD

Administrivia

Due Date by October 8, 2024 at 11:59 PM Questions: We will be using Piazza for all questions.

Collaboration: The assignment has to be done by yourself. Copying code (from others) is considered cheating. Read this for more info on what is OK and what is not. Please help us all have a good semester by not doing this.

This project is to be done on the lab machines, so you can learn more about programming in C on a typical UNIX-based platform (Linux).

A few sample tests are provided in the project repository. To run them, execute

in the

directory. Try

to learn

more about the testing script. Note these test cases are not complete, and you are encouraged to create more on your own.

Handing it in: Copy the whole project, including solution and tests folder, to Slip Days:

where

is your CS login.

In case you need extra time on projects, you each will have 2 slip days for the first 3 projects and 2 more for the final three. After the due date we will make a copy of the handin directory for on time grading.

To use a slip days or turn in your assignment late you will submit your files with an additional file that contains only a single digit number, which is the number of days late your assignment is (e.g. 1, 2, 3). Each consecutive day we will make a copy of any directories which contain one of these

files. This file must be present when you submit you final submission, or we won’t know to grade your code.

We will track your slip days and late submissions from project to project and begin to deduct percentages after you have used up your slip days.

After using up your slip days you can get up to 90% if turned in 1 day late, 80% for 2 days late, and 70% for 3 days late, but for any single assignment we won’t accept submissions after the third days without an exception. This means if you use both of your individual slip days on a single assignment you can only submit that assignment one additional day late for a total of 3 days late with a 10% deduction.

Any exception will need to be requested from the instructors. Example of slipdays.txt :

$ cat slipdays.txt 1

⚠Warnings⚠

This project will be checked for memory leaks!

This project will be examined during in-person code review sessions! This project is time consuming, start now!

Before you start – Makefile

The first task in this project is to create a

in a simple way. You can read more about

. A

and

is an easy and powerful way to define complex operations in your project and execute them using s in GNU’s Make Manual, Makefile Tutorial and Lab Tutorial.

Your must include at least following variables:

LOGIN

specifying the compiler. Please use or clang .

specifying the arguments for compilation. Use at least the following: specifying you login.

$^

specifying the path where you handin your files. has to be used at least once.

or has to be used at least once.

Your must include at least following targets:

is the first target in your

and runs

and

targets.

is a

target. Creating

target as a first target is a common

convention, since the first target is executed when is called without a target.

wsh

-O2

wsh

is a target which depends on

and

and builds the

binary with the compiler specified in

and compiler flags in CFLAGS . The

compilation must produce

optimized binary. Hence

will compile your code and create

binary.

is a target which depends on

and

and builds the

binary with the compiler specified in

and compiler flags in .

This binary is not optimized and is to be used for debugging with gdb . I.e. use binary.

flags.

will compile your code and create

by typing

moves binaries from the current directory. I.e. it just keeps source files. Must be called before submission.

target automatically submits your solution according to the submission instructions above. This means, that you should submit your project simply

.

We encourage you to create your own simple tests while developing your shell. It is very helpful to create a target in your Makefile , which will compile your

code and run all your tests. Like this, you can speed up your development and make sure, that every change in your source code still passes your tests (i.e. after every

change of you source code, you can just type and the shell will be compiled and tested).

Before beginning: Read

Unix Shell

and .

In this project, you’ll build a simple Unix shell. The shell is the heart of the command-line interface, and thus is central to the Unix/C programming environment. Mastering use of the shell is necessary to become proficient in this world; knowing how the shell itself is built is the focus of this project.

There are three specific objectives to this assignment:

To further familiarize yourself with the Linux programming environment. To learn how processes are created, destroyed, and managed.

To gain exposure to the necessary functionality in shells.

Overview

In this assignment, you will implement a command line interpreter (CLI) or, as it is more commonly known, a 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 shell you implement will be similar to, but simpler than, the one you run every day in Unix. If you don’t know what shell you are running, it’s probably or

(try echo $SHELL ). One thing you should do on your own time is to learn more about your shell, by reading the man pages or other online materials. Also, when you

are in doubt about some behavior in this assignment, try the behavior in (preferably) or ask on Piazza.

Program Specifications

wsh

Basic Shell:

before you ask. Maybe it makes things clear. Or not, and you will come to office hours

wsh

Your basic shell, called

(short for Wisconsin Shell, naturally), is basically an interactive loop: it repeatedly prints a prompt

(note the space after the

greater-than sign), parses the input, executes the command specified on that line of input, and waits for the command to finish. This is repeated until the user types

exit . The name of your final executable should be wsh .

The shell can be invoked with either no arguments or a single argument; anything else is an error. Here is the no-argument way:

prompt> ./wsh wsh>

wsh

At this point, is running, and ready to accept commands. Type away!

The mode above is called interactive mode, and allows the user to type commands directly. The shell also supports a batch mode, which instead reads input from a batch file and executes commands from therein. Here is how you run the shell with a batch file named script.wsh :

prompt> ./wsh script.wsh

One difference between batch and interactive modes: in interactive mode, a prompt is printed ( ). In batch mode, no prompt should be printed.

You should structure your shell such that it creates a process for each new command (the exception are commands, discussed below). Your basic shell

should be able to parse a command and run the program corresponding to the command. For example, if the user types cp -r /tmp /tmp2 , your shell should run

the program below).

Structure

Basic Shell

with the given arguments -r , /tmp and

(how does the shell know to run /bin/cp ? It’s something called the shell path; more on this

The shell is very simple (conceptually): it runs in a while loop, repeatedly asking for input to tell it what command to execute. It then executes that command. The loop continues indefinitely, until the user types the built-in command exit , at which point it exits. That’s it!

For reading lines of input, you should use and we guarantee that each token is delimited by a single space. Generally, the shell will be run in interactive

mode, where the user types a command (one at a time) and the shell acts on it. However, your shell will also support batch mode, in which the shell is given an input

file of commands; in this case, the shell should not read user input (from ) but rather from this file to get the commands to execute.

exit(0)

In either mode, if you hit the end-of-file marker (EOF), you should call and exit gracefully. EOF can be generated by pressing Ctrl-D .

To execute commands, look into brief overview.

, and wait()/waitpid() . See the man pages for these functions, and also read the relevant book chapter for a

You will note that there are a variety of commands in the

family; for this project, you must use execv . You should not use the

library function call to

run a command. Remember that if is successful, it will not return; if it does return, there was an error (e.g., the command does not exist). The most

challenging part is getting the arguments correctly specified.

Comments and executable scripts

In your shell, you should ignore all lines starting with # . Note that there can be spaces ( ) in front of # . These lines serve as comments in most shells you will work

with ( bash, zsh ).

Furthermore, once you implement comments, you should be able to create script, which can be directly executed. For example, if you put following script (let’s

wsh

call it script.wsh ) into a directory with your compiled binary, you must be able to run the script by typing ./script.wsh .

$ cat > script.wsh <<EOF #!./wsh

echo hello EOF

$ chmod +x script.wsh

$ ./script.wsh hello

If you are curious, the first line in the script ( #!./wsh ) is called shebang and it tells OS how to deal with this executable. There is a wiki page about it.

Redirections

Our shell will also support redirections as for example does. Please check Redirections in Bash Manual to learn about this powerful feature. To simplify the

wsh

assignment, supports only following and we guarantee, that the redirection token is always the last one on the command line, i.e. after all the command

parameters. Also there can be a at most one redirection per command.

Redirecting Input. The token always look like Redirecting Output. The token always look like

. I.e. no spaces around < .

. I.e. no spaces around > .

Appending Redirected Output. The token always look like . I.e. no spaces around >> .

Redirecting Standard Output and Standard Error at once. The token always look like Appending Standard Output and Standard Error at once. The token always look like

I.e. no spaces around &> .

. I.e. no spaces around &>> .

Examples of redirection:

wsh> echo hello &>>log.txt

wsh> cat <input.txt

Environment variables and shell variables

Every Linux process has its set of environment variables. These variables are stored in the about this.

Some important things about environment are the following:

extern variable. You should use

to learn more

1. When

   exec

is called, the child process gets a copy of the

variable.

1. When a system call from the

   family of calls is used, the new process is either given the

   variable as its environment or a user specified

   man environ

environment depending on the exact system call used. See man 3 exec .

1. There are functions such as more details.

and

that allow you to view and change the environment of the current process. See the

for

Shell variables are different from environment variables. They can only be used within shell commands, are only active for the current session of the shell, and are not inherited by any child processes created by the shell.

We use the built-in command to define and set a shell variable:

local MYSHELLVARNAME=somevalue

The variable never contains space () hence there is no need nor special meaning of quotes ( “” ). This variable can then be used in a command like so:

cd $MYSHELLVARNAME

which will translate to

cd somevalue

In our implementation of shell, a variable that does not exist should be replaced by an empty string. An assignment to an empty string will clear the variable.

Environment variables may be added or modified by using the built-in command like so:

export MYENVVARNAME=somevalue

After this command is executed, the variable will be present in the environment of any child processes spawned by the shell.

$

Variable substitution: Whenever the sign is used in a command, it is always followed by a variable name. Variable values should be directly substituted for their

names when the shell interprets the command. Tokens in our shell are always separated by white space, and variable names and values are guaranteed to each be a

ab

single token. For example, given the command mv $ab $cd, , you would need to replace variables and a shell variable, the environment variable takes precedence.

You can assume the following when handling variable assignment:

There will be at most one variable assignment per line.

Lines containing variable assignments will not include pipes or any other commands.

and cd . If a variable exists as both the environment variable

=

=

The entire value of the variable will be present on the same line, following the quotation marks surrounding the value.

operator. There will not be multi-line values; you do not need to worry about

Variable names and values will not contain spaces or characters.

There is no limit on the number of variables you should be able to assign.

Displaying Variables: The utility program (not a shell built-in) can be used to print the environment variables. For local variables, we use a built-in command in our

shell called vars . Vars will print all of the local variables and their values in the format <var>=<value> , one variable per line. Variables should be printed in insertion order, with the most recently created variables printing last. Updates to existing variables will modify them in-place in the variable list, without moving them around in the list. Here’s an example:

wsh> local a=b wsh> local c=d wsh> vars

a=b c=d wsh>

Paths

cp

In our original example in the beginning, the user typed and the shell knew it has to execute the program /bin/cp . How does your shell know this?

It turns out that the user must specify a path variable to describe the set of directories to search for executables; the set of directories that comprise the path are sometimes called the search path of the shell. The path variable contains the list of all directories to search, in order, when the user types a command.

cp

Important: Note that the shell itself does not implement or other commands (except built-ins). All it does is find those executables in one of the directories specified by path and create a new process to run them. Try to see where your shell looks for executables.

To check if a particular file exists in a directory and is executable, consider the system call. For example, when the user types cp , and path is set to

include both

and

(assuming empty path list at first,

is added, then

is added), try access(“/usr/bin/cp”, X_OK) . If that fails, try

/bin/cp . If that fails too, it is an error.

Your initial shell path should contain one directory:

or cd /usr; bin/ls .

Of course, your shell still can execute programs specified by full path, e.g. /usr/bin/ls , or relative path, e.g.

In general, the priority what to execute is following, where 1 is the highest priority:

1. Built-in.

2. Full or relative path.

3. Paths specified by $PATH .

History

Your shell will also keep track of the last five commands executed by the user. Use the builtin command to show the history list as shown here. If the same

wsh> history

1) man sleep

command is executed more than once consecutively, it should only be stored in the history list once. The most recent command is number one. Builtin commands should not be stored in the history.

2) man exec
3) rm -rf a
4) mkdir a
5) ps

n

By default, history should store up to five commands. The length of the history should be configurable, using history set <n> , where is an integer. If there are

fewer commands in the history than its capacity, simply print the commands that are stored (do not print blank lines for empty slots). If a larger history is shrunk using

history set , drop the commands which no longer fit into the history.

n

To execute a command from the history, use history <n> , where

is the nth command in the history. For example, running

in the above example

should execute again. Commands in the history list should not be recorded in the history when executed this way. This means that successive runs of

should run the same command repeatedly.

If history is called with an integer greater than the capacity of the history, or if history is called with a number that does not have a corresponding command yet, it will

do nothing, and the shell should print the next prompt.

Built-in Commands

Whenever your shell accepts a command, it should check whether the command is a built-in command or not. If it is, it should not be executed like other programs.

Instead, your shell will invoke your implementation of the built-in command. For example, to implement the your wsh source code, which then will exit the shell.

Here is the list of built-in commands for wsh :

built-in command, you simply call in

cd

: When the user types exit, your shell should simply call the system call with 0 as a parameter. It is an error to pass any arguments to exit .

cd :

always take one argument (0 or >1 args should be signaled as an error). To change directories, use the

system call with the argument

supplied by the user; if

Used as

: Used as

fails, that is also an error.

to create or assign variable to create or assign variable

as an environment variable. as a shell variable.

: Described earlier in the “environment variables and shell variables” section.

: Described earlier in the history section.

: Produces the same output as LANG=C ls -1 , however you cannot spawn parameters.

Miscellaneous Hints

program because this is a built-in. This built-in does not implement any

Remember to get the basic functionality of your shell working before worrying about all of the error conditions and end cases. For example, first get a single command running (probably first a command with no arguments, such as ps ).

Next, add built-in commands. Then, try working on command history, redirections, and variables. Each of these requires a little more effort on parsing, but each should not be too hard to implement. It is recommended that you separate the process of parsing and execution – parse first, look for syntax errors (if any), and then finally execute the commands.

We simplify the parsing by having a single space as the only allowed delimiter. It means that any token on the command line will be delimited by a single space in our tests.

Check the return codes of all system calls from the very beginning of your work. This will often catch errors in how you are invoking these new system calls. It’s also just good programming sense.

Beat up your own code! You are the best (and in this case, the only) tester of this code. Throw lots of different inputs at it and make sure the shell behaves well. Good code comes through testing; you must run many different tests to make sure things work as desired. Don’t be gentle – other users certainly won’t be.

.c

Finally, keep versions of your code. More advanced programmers will use a source control system such as git . You don’t need to push the repository to the Internet, but you can still do commits and benefit from the history tracking (this approach is recommended). Minimally, when you get a piece of functionality working, make a

copy of your 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.

wsh

Error conditions should result in terminating with an exit code of -1. Non-error conditions should result in an exit code of 0.