NOTE: This assignment, like the other projects in this class, is due at a particular time, listed above. This means that if you are even a minute late, you lose 20%. If you are worried about potentially being late, turn in your project ahead of time. Do this by submitting it electronically before the due date (the electronic copy is what is due by the time given above) then giving the hard copy to me or the TA during office hours or by sliding it under my office door (the hard copy is due within twenty-four hours after the electronic copy is due). Do not send assignments to my personal email address or to the personal email address of the TA. Do not leave hard copies in my departmental mail box or attempt to give them to departmental staff (who cannot and will not accept them).
As discussed in class, UNIX and UNIX-like systems have simple command-line interfaces available to users through shells. These can be effective and efficient ways for users to interact with their computers. However, they often lack the sophistication we might desire.
Consider, for example, the command-line method for moving (in most
cases, simply renaming) files: the mv utility program. By
default, mv will not warn the user if he or she accidentally
instructs the system to move a file to a pathname already occupied by
another file. Instead, it will quietly overwrite the other file, usually
resulting in its permanent loss. This is partially rectified by the
interactive flag (-i) that most modern versions of
mv accept. In this case, mv will warn the user
that a file is about to be overwritten and ask if this is the desired
behavior. While this is certainly an improvement over not informing the
user of the possible error, it is generally not enough to allow the user to
make an informed decision about whether to have the system overwrite the
file. Instead, the user might want to know about the relative dates of
last modification of the files, if the files differ from one another in
contents and if so how they differ, if there are differences in ownership
or access permissions between the files, etc. A typical shell session
involving mv -i might appear as follows:
% mv -i file1 ~/dir/subdir/file1
mv: overwrite `/home/user1234/dir/subdir/file1'? n
% ls -l file1
-rw------- 1 user1234 student 59775 Jul 15 21:06 file1
% ls -l ~/dir/subdir/file1
-rw------- 1 user1234 student 59775 Jun 12 10:47 /home/user1234/dir/subdir/file1
% diff -q file1 ~/dir/subdir/file1
Files file1 and /home/user1234/dir/subdir/file1 differ
% gvimdiff file1 ~/dir/subdir/file1
% mv file1 ~/dir/subdir/file1
Clearly, this requires a lot of effort on the part of the user. Similar
statements could be made about other utility programs, such as
cp.
One modification to existing utility programs that people might find useful, then, is one that assists them in obtaining the information they need in order to make intelligent decisions regarding overwriting or deleting files.
For this assignment, we'll implement our own versions of mv
and cp that provide for really interactive mode,
providing or offering to provide for the user the information that he or
she might need in order to make intelligent decisions regarding overwriting
or deleting files or directories. This really interactive mode will
be selected using the -I flag.
To really interactively move one file or directory the user will type:
mv -I <source> <destination>
where <source> is the pathname (either absolute or
relative) for the file or directory that the user wishes to move and
<destination> is the pathname to which the user wishes
to move <source>.
When invoked in this way, mv will check to see whether a
file or directory named <destination> already exists on
the system, then provide information to the user and prompt for action
appropriately, as follows:
If <source> is a file and a file with the name
<destination> already exists, mv will
inform the user whether or not the files differ in contents and whether or
not they differ in time of last modification, as appropriate. This
information will take the following form:
mv: <destination> exists
mv: <destination> <DOES | DOES NOT> differ from <source> in content
mv: <destination> is <NEWER than | OLDER than | the SAME AGE as> <source>
It will then prompt the user for further action. Possible user actions
include requesting additional information about the file, proceeding with
overwriting, or exiting without overwriting. If the user chooses to
request additional information about the file, the information will be
displayed and the prompt will be repeated. The prompt will appear as:
mv: overwrite `<destination>' (t, a, c, o, g, s, p, i, d, y, n)?
where the letters in the prompt refer to the following values:
<destination>, and
<destination>.
mv should look at the environment variable DIFF
to determine the program to use for displaying differences. If
DIFF is not set, mv should use
diff.
If <source> is a file and a directory with the
name <destination> already exists, mv will
look to see if a file with the filename portion of
<source> exists in <destination>. If
so, it will behave as above with respect to this file. If not,
mv will simply move <source> to
<destination>.
If <source> is a file and neither a file nor a
directory with the name <destination> already exists,
mv will simply move <source> to
<destination>.
If <source> is a directory and
<destination> is a file, mv will give the
following error message:
mv: cannot overwrite non-directory `<destination>' with directory `<source>'
If <source> is a directory and
<destination> is a directory, mv will look
to see if a file or directory with the name portion of
<source> exists in <destination>. If
so, mv will give the appropriate error message, either:
mv: cannot overwrite directory `<destination>'
or
mv: cannot overwrite non-directory `<destination>' with directory `<source>'
respectively. If not, mv will simply move
<source> to <destination>.
To really interactively move multiple files or directories the user will type:
mv -I <source_1> <source_2> ... <source_n> <destination>
where <source_1>, <source_2>, ...
<source_n> are the pathnames (either absolute or
relative) for the files or directories that the user wishes to move and
<destination> is the pathname of the directory to which
to which the user wishes to move <source>.
When invoked in this way, mv will check to see whether
<destination> is, in fact, a directory. If it is not,
mv will give the error message:
mv: when moving multiple files, last argument must be a directory
If <destination> is a directory, mv will
proceed as though invoked as above one time for each
<source_i>.
To really interactively copy files or directories the user will type:
cp -I <source> <destination>
or
cp -I <source_1> <source_2> ... <source_n> <destination>
respectively, depending on whether he or she wants to copy a single source
(file or directory) or multiple sources (files or directories).
In all respects, with the exception of removing the source(s), cp
-I will behave just the same as mv -I.
Some parts of the assignment above may be vague or incomplete. This is intentional. This is to give you experience with the way software development is done in "the real world" (industry, academia outside the classroom, government labs, etc.). Often you will get problem descriptions that are vague or incomplete, even if they seem concrete and complete initially.
You should read through the assignment carefully, look for ambiguities or cases not covered, then ask about them, either in office hours or through email, as soon as you can. (Recall that those people who come to office hours get priority over those who call during office hours who, in turn, get priority over those who send email.) If you wait until the last minute to ask about ambiguities or missing cases, you may not get an answer before your project is due. If you don't get an answer in time (or at all, if you don't ask), then you will have to guess how to handle certain situations. If you guess wrong, you will lose points.
You will turn in both a hard copy and an electronic copy of your assignment. Please follow the instructions on how to send electronic copies. Do not send them to my email address.
Both the hard copy and the electronic copy will contain a write-up and
all source code you used in this project. The electronic copy will also
contain the executable versions of your code. The electronic copy of your
write-up should not be in a proprietary format (such as MS Word); it should
be either in plain ASCII text or in a portable format (such as Postscript
or PDF). Your source code should be in two files called mv.c
and cp.c (for C code) or mv.cxx and
cp.cxx (for C++ code) and your executable files should be
called mv and cp.
Your source code should be well structured and well commented. It should conform to good coding standards (e.g., no memory leaks).
Your write-up will include 1/2 to 1 page (roughly 80 characters per line, 50 lines per page) explaining the data structures and algorithms used in your code. This page limitation does not include figures used in your explanation, which are encouraged and may take up any amount of space. (This explanation does not remove the requirement that your code be well commented.)
You may write your program from scratch or may start from programs for which the source code is freely available on the web or through other sources (such as friends or student organizations). If you do not start from scratch, you must give a complete and accurate accounting of where all of your code came from and indicate which parts are original or changed, and which you got from which other source. Failure to give credit where credit is due is academic fraud and will be dealt with accordingly.
As noted in the syllabus, you are required to work on this programming assignment in a group of at least two people. It is your responsibility to find other group members and work with them. The group should turn in only one (1) hard copy and one (1) electronic copy of the assignment. Both the electronic and hard copies should contain the names and student ID numbers of all group members. If your group composition changes during the course of working on this assignment (for example, a group of five splits into a group of two and a separate group of three), this must be clearly indicated in your write-up, including the names and student ID numbers of everyone involved.
Each group member is required to contribute equally to each project, as far as is possible. You must thoroughly document which group members were involved in each part of the project. For example, if you have three functions in your program and one function was written by group member one, the second was written by group member two, and the third was written jointly and equally by group members three and four, both your write-up and the comments in your code must clearly indicate this division of labor.