辅导 CSC209、讲解 C/C++设计编程
1/11
A3: CSCSHELL
Due Sunday by 11:59p.m.
Points 200
Available after Feb 14 at 12a.m.
A3 – CSCSHELL
CSC209 Winter 2024
Last updated (Mar 15th): See 5.7
Table of Contents
1. Introduction
2. Starter Files
2.1. Actually getting started
3. CSCSHELL
4. Limitations (shell stuff you won’t have to implement)
5. Implementation and Requirements
5.1. Managing errors
5.2. Shell Variables
5.2.1. Creation
5.2.2. Usage
5.2.3. PATH
5.2.4. Error checking with variable assignment
5.3. Scripts and .cscsh_init
5.4. Execution
5.4.1. The cd command
5.5. File redirection
5.6. Piping
5.7. Notes and Clarifications (check here for any updates)
6. Marking
1. Introduction
In our first few lectures together we learned the basic “syntax” of the command line. We talked a little bit
about terminal programs, and this thing called BASH, or more generally the shell. In this assignment, you
will be implementing a basic shell that can perform many, if not all of the operations we’ve needed in the
course thus far (to my surprise, the man pages, and vi are also supported, at least on teach.cs and my
own machine). It will be able to use the system to start executables (ones with appropriate permissions)
found in any directory listed in a special $PATH variable as well as any with an absolute or relative path
CSCSHELL
2/11
(e.g. if you typed ./hello ) Of course, you’ll be able to also supply command line arguments to these
programs. This shell will be interactive as well as mildly scriptable. When “interactive”, typing into the
terminal program (itself running your shell program) will provide input to the stdin of other running
executables, as well as display the output of stdout and stderr . Really, what you're already used to at
the "command line", but written by you! Ultimately, it will support file redirection, piping, and reading
commands from a script file, so you are not solely limited to interactive usage of this shell.
While we won’t be able to exhaustively support any and all programs, that are say, installed on teach.cs
(this would require continual maintenance and bug-fixing), we will be able to use the basic system
programs we’ve learned to use, like cd (in fact, a special case), ls , mkdir, rm, grep, touch, man,
cat, wc etc. -- as well as all the programs you have developed for the course.
This assignment will feature a lot of C-string parsing, file i/o, as well as standard usage of the system call
(families): fork , exec , wait , pipe and dup .
2. Starter Files
The header file cscshell.h has lot’s more information to get you started. Please do not remove or edit
anything that is already there, but feel free to add more function declarations, macros, and any libraries
that don’t need linking and are available on teach.cs.
Do not change the struct definitions, the tester will be using these, so you're stuck with them.
In addition to cscshell.h , there is the accompanying cscshell.c which features the main() entry point
for your program. This source file should not need to be changed. If you do, you may only add
functionality, and not remove any existing functionality (also we won’t be testing any of the additional
functionality that you add).
The files parse.c and run.c are the two main parts of this assignment. Every function you implement
should be added to one of these two files, depending on if it is for parsing shell text, or running
processes/other executables.
2.1. Actually getting started
The material you will need for the system-call aspect of this assignment will not be covered in class until
weeks 7 and 8, so get started with parsing the shell syntax as soon as you can (since you have
everything you’ll need for this), and start asking yourself what would you need to be able to do the rest.
The source files include a lot of additional information meant to direct you towards successfully
completing the assignment, as well as some helpers and partially completed functions. Feel free to start
from scratch according to cscshell.h if you're that kind of person.
3. CSCSHELL
CSCSHELL
3/11
This shell will be similar to POSIX sh
(https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html) (much like BASH
(https://www.gnu.org/software/bash/) ; which you find on the teach.cs machines, Ubunutu, or the WSL; or
zsh
(https://wiki.archlinux.org/title/zsh#:~:text=Zsh%20is%20a%20powerful%20shell,improved%20tab%20comple
; which you find on your Apple products). We will however keep it profoundly simplified, focusing on the
following features:
1. Comments: anything trailing a # character on any line is a comment and thus ignored
2. Variable assignment and usage. See 5.2.
3. Script execution, including a mandatory init script that must initially define a ${PATH} variable at
some point
4. A cd command, as this is not an executable, it is system control access provided by a shell
5. Using system calls to start executables with arbitrary string arguments. Programs are the first part of
any usable line of CSCSHELL (provided it is not cd , variable assignment or a comment), and can be
either a name found in one of the ${PATH} directories, or an unambiguous path to the program
(relative or absolute are both acceptable).
6. File redirection from stdout to new (or re-creating existing) files or appending to existing ones, as
well as redirection from a file to stdin
7. Piping between the stdout of one program and the stdin of the next. All processes must run
simultaneously.
4. Limitations (shell stuff you won’t have to implement)
Even the most basic POSIX sh (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html)
supports many more features, and is in fact, a fairly comprehensive scripting language. We will not be
implementing any features aside from what is listed in 3. Some obvious limitations:
1. No support for meta-characters/matching, e.g. '*'
2. Loops, conditionals, general programmatic scripting features
3. Command line arguments to the scripts (somewhat pointless without 2.)
4. Redirection to/with file descriptors numbers (through shell syntax)
5. Command history and tab-completion
Furthermore, having only one environment variable ( $PATH ) is fairly limiting, and so is maintaining the
variables as a linked list. If you are really into this work, I’d suggest extending the shell with some of
these missing features if you’re ever looking for exercises to do.
5. Implementation and Requirements
5.1. Managing errors
CSCSHELL
4/11
Errors that are due to system failures e.g. like malloc running out of memory should cause the shell to
terminate. However, errors pertaining to the usage of CSCSHELL should be handled gracefully without
ending the shell, these should just print an error message. The header cscshell.h lists a variety of
macros with (formatting) strings to print to stderr when something goes wrong. You will find examples in
cscshell.c about how to use them, specifically using ERR_PRINT . If you can’t decide which error to use,
use the general-purpose error:
#define ERR_EXECUTE_LINE "Could not execute line.\n"
Update: You may use any error message with the ERR_PRINT macro to pass the automated tests.
There need not be any confusion as to which message to use. Note that good messages will help you
debug.
5.2. Shell Variables
5.2.1. Creation
Shell variables must be specified as a name, consisting of only alphabetic characters and _
(underscore) characters. Variable values are a string that can contain any ASCII characters.
Note that the newline character for a line is not part of the variables value.
A single = must separate the variable name and the value, without any spaces in between the name
and '=' . There can be spaces in the variables value, and the value can also be empty (nothing, or
simply whitespace after '=' ). This means that you might also find extra whitespace, including '\t'
( '\n' and '\r' gets messy when using fgets to read input, so we will relax this and not worry about it).
This whitespace does not need to be removed from the value. Some extreme, but correct variable
assignments might look like this:
PATH=Some Text, that can definitely include spaces.
OTHER_VAR=Example Has Special(tab) Whitespace.
EMPTY_VAR_ONE=
EMPTY_VAR_TWO=
Note: EMPTY_VAR_TWO actually has some spaces as a value, EMPTY_VAR_ONE does not, highlight the
whitespace with your cursor to see more clearly.
Some examples of incorrect assignment are as follows:
BAD_VAR2=It has a number in the name
Badvar =Shouldn't have a space before the equal sign.
ls > THING=this is just very wrong, hopefully it is clear why!
Note: Quotations will be simply assumed to be part of the string, hopefully making your job way easier.
Therefore, in this example:
OTHR_VAR="hello world"
CSCSHELL
5/11
The name of the variable is OTHR_VAR and it’s value includes the quotes, storing: "hello world" (13
characters – and a null terminator as a C-string).
Finally, notice if you type the literal escape sequence '\t' or '\n' , that these are interpreted as two
characters, but since we don’t use TAB for autocomplete in this shell, using the TAB key will give you a
'\t' character, in the form of inserting a big whitespace (and the C char value '\t' ). Refer back to
OTHR_VAR above.
5.2.2. Usage
Clarification (Mar-04): it is acceptable in this assignments for variables to only ever be used in
commands, as in, usage is not considered during creation (don't need to support $VAR=Use some
$OTHER value, you can support this if you want).
1. Simple
Variable usage in the shell consists of a prefixed $ before the variable’s name. As in:
SPECIAL_FILE=/etc/password
echo "The file: $SPECIAL_FILE does not really exist."
Note: this is ambiguous if you’d like to combine the variable with symbols that are valid variable
characters. The end of the variable is clear because of the space, but instead, consider:
PROJECT_DIR=a3/solution/
gcc -Wall -std=gnu99 -c $PROJECT_DIRcscshell.c
The end of the variable is ambiguous!
2. Unambiguous
The unambiguous variable usage does not rely on a invalid name character to demarcate the end of
the variable, and instead adds curly braces {} on either side of the name to make this
unambiguous.
Consider how this fixes the issue in 5.2.2.1:
PROJECT_DIR=a3/solution/
gcc -Wall -std=gnu99 -g -o solution ${PROJECT_DIR}cscshell.c
5.2.3. PATH
This variable is just like the $PATH variable in the shell on teach.cs. Try printing it out with echo $PATH .
Essentially, it is a set of paths to directories, separated by colons. The trailing / is optional for any path
on the $PATH . In the interest of quick and syntactically seamless O(1) access, maintain this variable as
the head of the variable list!
5.2.4. Error checking with variable assignment
CSCSHELL
6/11
A few error conditions should be checked when parsing variable assignments. cscshell.h lists errors
that will need checking for convenient macros) to stderr . The following two macros are provided for
error checking pertaining to variable assignment specifically.
#define ERR_VAR_START "Assignment cannot start with '=' character.\n"
#define ERR_VAR_NAME "Variable names must only contain alphabetic characters and\
'_' chars.\n Got: %s\n"
1. (Hint) Don’t consider variable assignment mixed with pipes or redirection
Notice that the command MY_VAR="something" | grep foo is nonsensical, there is no stdin or stdout
relating to variable assignment.
Your solution should handle the above example by creating (or updating) the variable MY_VAR to have
the (string) value "something" | grep foo .
We will not test the similarly nonsensical ls | MY_VAR="something" .
2. (Hint) All the text to be parsed will be ASCII-formatted
Thus, you can use the character codes/numeric ranges to do error checking and parsing if you so
desire.
5.3. Scripts and .cscsh_init
Scripts should operate as if each line in the file were typed into the shell program one at a time. Except…
You won’t have to type it interactively.
Therefore the code provided for running the shell interactively should provide you a great example of
how to use the functions to implement run_script . Notice that we use run_script to start the shell’s
“init” file. Be sure to go over the source code we give you before starting!
Finally, you’ll eventually notice that running your shell program on teach.cs through ssh will probably
result in a broken backspace. Running the command stty sane should be enough to sort this issue, so
consider adding this to your CSCSHELL’s init file, as well as the following path variable assignment to
access the basic utilties:
PATH=/local/bin:/usr/bin:/bin/
stty sane
You can download this as a .cscshell_init file here (https://q.utoronto.ca/courses/337029/files/30784621?
wrap=1) (https://q.utoronto.ca/courses/337029/files/30784621/download?download_frd=1) . Note that the
leading dot '.' in the filename means it is a hidden file. You can see hidden files with the 'a' option in ls, as
in, with '-l': ls -la
5.4. Execution
CSCSHELL
7/11
The name (for an executable file in one of the $PATH paths) or path (relative or absolute) to an
executable file is the first non-whitespace aspect of any shell “command” (or line) unless it is one of
these three (four) exceptions:
1. Variable assignment
2. The cd command (https://q.utoronto.ca/#org6294c43)
3. Comments
4. (blank lines)
This means, aside from piping, in which case there are multiple commands, the name of the “command”,
i.e. some executable identified via $PATH or directly with an absolute or relative path, must be the first
part of each “command”. Subsequent strings on a line are arguments to this command, unless they
are cases of 5.6 or 5.5. Arguments are separated from each other (and the command) by one-or-more
spaces (not tabs or new-line or carriage whitespace etc).
Standard execution of lines shall require one child process per executable that needs to be run. The
parent process for the shell must wait (using the wait family of system calls) for the child process to
complete.
5.4.1. The cd command
Unlike ls , your other bread-and-butter shell command cd is not an executable. Notice that cd has no
sensical stdin/out .
We’ve provided you the helper function cd_cscshell , which you should use in execute_line to actually
change directories. Your cd command must accept either no arguments or one additional argument.
With no arguments, the command should move to the current user’s home directory. Type man getpwuid
and notice the pw_dir member of struct passwd , and take a moment to understand what makes
prompt() in cscshell.c work.
If one or more arguments are provided, your cd should use the first argument as a relative or absolute
path and just ignore the rest if provided. The special paths of '.' and '..' should also work.
5.5. File redirection
File redirection must be specified after all arguments for commands (see 5.4) have been specified. In
other words ls -l > out.txt is correct, but ls > out.txt -l is not (because the -l is after the
redirection). You must support all three redirection possibilities, and mixing up to one output redirection
and one input redirection:
1. Input redirection “<”, e.g. grep keyword < file_to_search.txt
2. Output redirection “>”, e.g. ls -l > output.txt
3. Output redirection as appending “>>”, e.g. ls -lah --author >> directory_history_snapshots.txt
With two re-directions, as in wc -l < contacts.txt > num_contacts.txt the order of input or output
redirection is irrelevant, either one may go first. You cannot mix both output redirection ( ">" ) as well as
CSCSHELL
8/11
appending the redirected output ( ">>" ).
We will not be implementing support for input appending ( << ).
5.6. Piping
Valid combinations of piping mixed with redirection should work, but there are invalid configurations
(though these can be overcome leveraging the program tee , see man tee ).
The following is an invalid combination, that BASH gracefully ignores:
ls -l > out.txt | grep l
You should not implement a tee -like solution (i.e. pipe stdout from ls and write to out.txt ) to handle
the above. You should either print an error, or simply write to out.txt without causing grep to hang
(waiting on a pipe).
So long as your shell program does not exit (i.e. segfault or intentionally exit operation), you may handle
invalid piping and redirection combinations as you see fit!
Otherwise, in general, a child process should be created for each executable listed on a single line. They
must, of course, be separated by a pipe character | (refreshing your memory on pipes in BASH my be
helpful).
The leftmost process should write its stdout to the write-end of a pipe, whose read-end is connected to
the stdin of the next program in the pipe sequence. The stdin for the first program is unaffected by
pipes, as is the final program’s stdout . That is, they should either connect to the default (terminal)
stdin/out or be subject to 5.5.
5.7. Notes and Clarifications (check here for any updates)
5.7.1. Before assignment release
Leading whitespace before commands or any other function are acceptable and must be simply
ignored.
5.7.2 Feb 28th run_command and some suggestions
It should have been clearer in the source code comments, but run_command 's return value should be
the child's PID (HINT: run_command should only start one command at a time, multiple processes are
expected to be managed in execute_line ). The parent process (the original shell process) should be
the one returning this PID. Another HINT: it should return this to execute_line where the waiting
happens on all the running children.
Note: The parent process is always the one that is providing prompts, or reading from a script.
Getting parse_line (and consequently replace_variables_mk_line ) to be bug free is going to take
time, but try not to leave run.c until the last minute. As of week-7, you have everything you need to
start new processes and exec executables, but it won't be until week-8 that you will learn how to
CSCSHELL
9/11
make the pipes that connect processes, and the file-descriptor management that goes along with
this.
5.7.3 Mar 4th The parse_line implementation, Using '=' outside of variable assignment, and other
variables in new variable creation
For simplicity, feel free to assume that if there is a valid (not-commented) ' =' character, that the
intent of a line is that it be a variable assignment. So you can assume if = in line; then variable
assignment, without penalty. This of course breaks compatibility with command line args of the form
--option=, but we will not worry about it. It shall, of course, also be acceptable to support =
signs well. As in, if = with no *space before it; then variable assignment; else it is command
execution. Thanks to Piazza @1702 for discussion.
The command struct returned by parse_line must be complete (as in, all fields contain their final
values), aside from the following: stdin_fd and stdout_fd may be used as you see fit, when you
see fit, and their values will not be tested directly (only the expected functionality of the shell itself will
be tested, as in, if I ls -l > file.txt then I'd expect at some point that stdout_fd be connected to
an open file called file.txt , but we will only test if the file actually gets the right bytes written to it!).
Thanks to Piazza @1708 for bringing this up.
5.2 has been updated, pertaining to: It is acceptable in this assignments for variables to only ever be
used in commands, as in, usage is not considered during creation (don't need to support $VAR=Use
some $OTHER value , you can support this if you want).
Other, more general clarifications:
The goal of this assignment it to complete a working shell
That is, after you run cscshell your terminal should work a lot like normal, just now it will be
slightly more limited (as described above), and use a shell implementation that you've written.
How are you expected to complete the assignment? There are no programmatic steps to follow...
Besides using the design provided.
Start from main, trace out what will need to happen to start a shell, which can execute
something like ls
The functions listed in cscshell.h are a bit of a puzzle to piece together through a couple
exercises like this
5.7.4 March 4th Part 2: Command structs
Clarification: The command struct's members will be tested and are as follows:
exec_path: (tests will examine this) The path to the literal executable run, returned by
resolve_executable
args: (tests will examine, but will ignore index 0) These are the argv arguments to your program.
You may re-use the exec_path for argv[0].
next: (tested to retrieve the whole list) the next command if a line contains multiple commands
stdin_fd: (untested) an integer to store fd's for the process' stdin
stdout_fd: (untested) same as above for stdout
CSCSHELL
10/11
redir_in_path: (tested) for input redirection, should match the exact (relative or absolute) path
provided on the original line
redir_out_path: (tested) same as above
redir_append: (tested) non-zero if and only if the command is redirecting and appending to the
destination
The only members considered/needed for a 'cd' command are exec_path and args[1], noting that
resolve_executable already returns a string literal for cd in this case.
5.7.5 Update to 5.3
The shell instruction suggestions originally in 5.3 were in the wrong order
It should be
PATH=/local/bin:/usr/bin:/bin/
stty sane
Download a copy of the file (https://q.utoronto.ca/courses/337029/files/30784478?wrap=1)
(https://q.utoronto.ca/courses/337029/files/30784478/download?download_frd=1)
5.7.6 Confirmation of ERR_PRINT and testing; invalid piping testing
Any string may be used to pass the automated tests, as long as you use the ERR_PRINT macro (or
equivalent).
Feel free to use whatever message makes the most sense to you, we will be checking for
"ERROR:" in stderr, or the lackthereof
Invalid combinations of piping and redirection will not be extensively tested, section 5.6 has been
clarified to this effect
"So long as your shell program does not exit (i.e. segfault or intentionally exit operation), you may
handle invalid piping and redirection combinations as you see fit!"
5.7.7 Parsing redirects and pipes without spacing
This question has come up a few times
If there are no spaces around redirect symbols or pipes, this is still considered valid
So you should handle cases like ls>out.txt and ls|grep file
5.7.8 Minor clarifications from Piazza
You don't need to support && or ; operators. Or while or for or if for that matter :)
If you can't make a valid command struct from the line, you should throw an error in parse_line
The sanity tests are there for some feedback, they reflect your code's conformance to my solution,
not the more flexible notion of cscshell behaviour, if it is "working" on teach.cs but not passing tests, it
could just be because, say, you managed your file descriptors in different functions than I did. My
guess is that you are calling dup in execute line rather than run_command, and that's fine, but the
sanity tests won't work.
We will run your shell as a standalone program for the remaining tests, and not rely on these sorts of
design decisions, so the final results will be different.
CSCSHELL
11/11
6. Marking
This assignment will be marked in a very similar fashion to what you’ve seen so far.
75% will test the core functionality outlined in this document
15% will be style graded by the TA as per the rest of the course
5% will be specifically awarded for the correct usage of perror for all system calls
5% will be specifically awarded for effective parallelism using pipes