Updated: 2015-01-26 15:34 EST

1 Due Date and Deliverables

Do not print this assignment on paper!

WARNING: Some inattentive students upload Assignment #02 into the Assignment #01 upload area. Don’t make that mistake! Be exact.

2 Purpose of this Assignment

Do not print this assignment on paper! On paper, you cannot follow any of the hyperlink URLs that lead you to hints and course notes relevant to answering a question.

  1. More review of basic Linux command line operations and utilities, e.g. from CST8207 GNU/Linux Operating Systems I.
  2. Explore the PATH mechanism of the shell
  3. Verify why putting the current directory in your PATH is undesirable
  4. Create simple shell scripts

3 Introduction and Overview

This is an overview of how you are expected to complete this assignment. Read all the words before you start working.

You will create file system structure in your CLS HOME directory, including various directories, files, and links.

You can use the Checking Program to check your work as you do the tasks. You can check your work with the checking program as often as you like before you submit your mark, and you can submit your mark as many times as you like before the due date.

Some tasks sections below require you to finish the whole section before running the checking program; you may not always be able to run the checking program successfully after every single task step.

When you are finished the tasks, leave these files, directories, and links in place as part of your deliverables. Do not delete any assignment work until after the term is over! Assignments may be re-marked at any time; you must have your term work available right until term end.

This is partially a review lab, and some of the tasks can be completed with knowledge of the material from the prerequisite course CST8207 GNU/Linux Operating Systems I; however, you will probably need to refresh your memory of various topics by referring to the CST8207 course notes and the Linux man pages. Your lab instructor is there to help you, but s/he will want you to have tried consulting the notes and man pages first.

The first tasks guide you through the process of reviewing the Search Path mechanism of the shell. In the process, you will gain some practice working with Shell Variables.

The remaining tasks involve creating simple shell scripts. This lab uses basic scripting techniques, to be built upon in future labs. You can use the Checking Program to check your work after you create each script.

3.1 The Source Directory

All references to the Source Directory below are to the CLS directory ~idallen/cst8177/15w/assignment02/ and that name starts with a tilde character ~ followed by a user name with no intervening slash. The leading tilde indicates to the shell that the pathname starts with the HOME directory of the account idallen (seven letters).

You do not have permission to list the names of all the files in the Source Directory, but you can access any files whose names you already know.

3.2 Searching the course notes on the CLS

The previous term’s course notes are available on the Internet here: CST8207 GNU/Linux Operating Systems I. All the notes files are also searchable on the CLS. You can recall how to read and search these files using the command line on the CLS under the heading Copies of the CST8207 course notes near the bottom of the page Course Linux Server Course Notes.

4 Tasks

For full marks, follow these task directions below exactly as written. READ ALL THE WORDS to work effectively and not waste your time.

  1. Complete the Tasks listed below, in order, from top to bottom.
  2. Do not skip steps.
  3. These tasks must be done in your account on the Course Linux Server.
  4. Verify your own work before running the Checking Program.
  5. Run the Checking Program to help you find errors and grade your work.
  6. Submit the grading output of the Checking Program to Blackboard before the due date.

Your instructor will also mark on the due date the work you do in your account on the CLS. Leave all your work on the CLS and do not modify it. Do not delete any assignment work from the CLS until after the course is over.

4.1 Set Up – The Base Directory on the CLS

  1. Do a Remote Login to the Course Linux Server (CLS) from any existing computer, using the host name appropriate for whether you are on-campus or off-campus. All work in this assignment must be done on the CLS.

  2. Make the CLS directory ~/CST8177-15W/Assignments/assignment02, in which you will create the files and links resulting from the following tasks.

This CLS assignment02 directory is the Base Directory for most pathnames in this assignment. Store your files and answers in this Base Directory on the CLS.

  1. Create the check symbolic link needed to run the Checking Program, as described in the section Checking Program below.

Use the symbolic link to run the Checking Program to verify your work so far.

4.2 Exploring the search PATH mechanism

This task explores the shell Search Path.

NOTE: In this task, you will change the PATH variable temporarily for the current shell session only. If at any time you want to undo these temporary changes, you can simply exit the shell that has the changes and then start a new shell, or re-login if you exited your login shell. (Below, we suggest you create a subshell so that you don’t log out when you exit!)

Since this task involves temporary changes to shell variables, you cannot resume this task in the middle if you log out or exit the shell. You must always start this task over from the beginning.

Do NOT edit your .bashrc to make permanent changes that affect future login sessions, unless explicitly told to do so.

  1. Start a second copy of bash (a nested shell or subshell). (Watch the MP4 video on Subshells. Some sysadmin like to put the nesting level of the shell in their prompt using the $SHLVL variable.) You can use the ps command to verify that you have two copies of bash running. Re-read the NOTE, above.

  2. Display the value of the shell environment variable PATH on your screen and verify that the standard system directory /bin is in the list of directories in your shell’s search PATH. (If the /bin directory is not listed in your PATH, something is very wrong; contact your instructor.)

    Hints: There are several ways to see the value of an environment variable (or local variable) on your screen. You could use a command that shows single lines of text on your screen. Review Shell Variables.

  3. Use a command to discover which of your PATH directories contains the ls program. Use redirection to put the output of this command (the absolute path to the ls command) in file lspath.txt in your Base Directory. You will need to know this pathname later.

  4. Store the current value of your PATH variable in a new shell variable named oldpath by entering a shell assignment statement oldpath=$PATH (no blanks). Make sure that both variables PATH and oldpath have the same values.

    Hints: Some commands that can display the value of environment variable PATH cannot be used to display the value of the new local non-environment variable oldpath. Choose correctly. Since setting the value of a shell variable doesn’t save it on disk, the saved value in oldpath is temporary, only valid for this shell. The value will be lost if you exit this shell and start a new shell. If you exit this shell before completing this task, you will lose the value of oldpath and must start the task over from the beginning.

  5. Put the value of the shell variable oldpath into a new file named savepath.txt in your Base Directory. Hint: Display the value of the variable and use output redirection to put it into the file. It’s easy and accurate.

  6. Remove all write permissions from the savepath.txt file, so that you don’t accidentally overwrite it.

  7. Set your PATH variable to have no value. One method is to type nothing after the equals sign – just push Enter after the equals: PATH= 
    Use echo to display the new (empty) value of PATH on your screen. (Most other commands will not be found; echo is built-in to the shell and doesn’t need a valid search PATH.)

  8. Try to run any non-builtin command (for example, ls, who, date, etc.) and notice that the attempt fails because the shell cannot find a program with that name in your current (empty) search PATH. Type the ls command name and use the correct syntax to redirect just the shell error message into a file called path_error.txt in your Base Directory.

    Hints: Recall how to redirect errors using shell Shell I/O Redirection. Display the contents of the file to make sure the error message is in the file: If you use the right absolute command pathname, you can run a file display command even if no commands can be found because of the empty PATH variable of the current shell. See the next question for an example of using an absolute pathname as a command name.

  9. Run the ls program using its absolute pathname (the one you discovered and saved earlier). You do not need any directories in your PATH to run a command using a pathname containing slashes. The PATH is not used to look for command names containing slashes, as explained in Search Path.

  10. Issue a shell built-in command (for example, echo, pwd, shopt) and verify that built-in commands are part of the shell process itself and also do not need to be found in PATH directories.

  11. Redirect the output of shell built-in shopt into a file called shopt.txt in your Base Directory. Because this is a shell built-in command, the search PATH is not used and the command works fine.

  12. Restore your PATH variable to its original value by restoring its value from the oldpath variable.

    Hints: This is the reverse shell assignment statement compared to what you did earlier to save the value: simply exchange the names. If you make a mistake, re-read the NOTE, above.

  13. Display your PATH variable to verify it is restored (has the same value as in the variable oldpath).

  14. Try a few non-builtin commands to verify they are found with the restored PATH in place.

  15. Exit the nested sub-shell and return to your original login shell.

Check your work so far using the check program symlink.

4.3 Creating your first shell script

  1. In the Base Directory create the file myworld.sh, containing the following two lines:
    1. The first line of the file should be exactly these 12 characters: #!/bin/sh -u
      (plus one more character for the newline at the end of the line).
    2. The second line of the file should be a command that displays the exact text: *** It's not a "Micro$oft" World. *** on the screen. Make sure you count the asterisks and get the capitalization, quotes, dollar sign, and period correct. You will test that you got this right in the next few steps.
  2. Make the myworld.sh file executable for only the owner (you). Group and others can read the file but not write or execute it. Hint: Review Permissions from last term.

  3. Execute the script in the current directory and edit it to fix any errors. When the output of the script is correct on your screen, redirect the output into file outworld.txt in the Base Directory.

    Hints: Execute the script by typing its name. You will note that the shell cannot find myworld.sh as an executable command name with no slashes, because the command is not on your search PATH. You need to avoid the search PATH by using a relative pathname containing a slash to execute this file, just as you do when executing the check symlink. Review Executing a program in the current directory.)

You have just finished creating your own very simple Linux command – a script that prints some text to its standard output. Linux sysadmin create dozens of command scripts that do various system administration tasks. The scripts eliminate typing errors and make repeating tasks much easier.

  1. Create the directory bin in your own HOME directory as a place to keep your own personal commands. Hint: Make sure you create this directory in your own HOME directory.

  2. We will give our new command a more command-like name, without the file extension. We will at the same time link the new name into our private bin directory that we just created. To do this, create a hard link from your myworld.sh script to the name myworld (no extension) inside your bin directory. You now have one file inode with two names. Hint: Review Links and Inodes.

  3. Make the Base Directory your current directory. Now, without changing directories again, use a command to display the inode numbers and names of both script files to verify that they are hard links to the same inode. Use one command with two relative pathnames. When the two output lines are correct (showing the relative pathnames and the identical inode numbers), save the output into file sameinodes.txt in the current (base) directory.

  4. Change to your HOME directory. Without changing directories again, execute your new myworld command that is inside your bin directory using the shortest relative pathname (from your HOME). This pathname will contain one slash. Put the relative pathname you used into file relbin.txt in your Base Directory.

    Hint: A fast way to create relbin.txt is to echo the pathname that you just used and use redirection to create the file in the Base Directory.

  5. Start a subshell. Append the absolute pathname of your new bin directory to the right end (not the start) of the PATH variable of your current shell. Remember how you did this – you will need to do it again later in your .bashrc file. Hint: Review Appending to PATH.

  6. Display your PATH to confirm that the absolute path of your bin directory is on the right end (not at the start). do not add the directory more than once – it should only appear once in your PATH variable. If you need to start over, exit this subshell and then start another one to get a fresh, good copy of PATH.

  7. if you have done the previous steps correctly, you can now type the command name myworld (no slashes, no file extension) and the shell will find your myworld script in your bin directory and execute it (because your bin directory is now in the PATH for this shell).

    Hint: Now that your bin directory is in your search PATH, you can use the TAB key to do command name completion on the myworld command name, so you don’t have to type the whole name. Type my and then TAB and let the shell do your typing for you!

  8. When you have your own myworld command working using your modified PATH variable, save a copy of your modified PATH variable in file binpath.txt in your Base Directory. Make sure there are no duplicate directories in PATH before you save it. Your HOME bin directory must be at the end.

The change we just made to this shell’s PATH variable will be lost when the shell exits. We need to save this change so that it happens every time we log in. We do this using the .bashrc file.

  1. Create a backup copy of your .bashrc file, in case you need to start over.

  2. Make the necessary changes to your .bashrc file to add the absolute path of your bin directory to the right end of your PATH variable. The syntax to do this is exactly as you did earlier with your interactive shell. Save the file.

  3. Log out and log in to have your .bashrc execute. Check your PATH variable to make sure the absolute path of your bin directory is at the right end of your PATH. Verify that your myworld command from your own bin directory still works (no slashes). The shell will do command completion on this name if you use the TAB key.

You will note that every time you start a new nested subshell, your .bashrc appends another copy of your HOME bin to your shell’s search PATH variable. We will learn in later assignments how to avoid this duplication.

Check your work so far using the check program symlink.

4.4 Putting the current directory in PATH is a bad idea

  1. Make your HOME directory your current directory.

  2. Create a fake ls command using these steps:
    1. Copy the myworld script you created above to a new file named ls in the current (your HOME) directory.
    2. Edit the new file, changing the text message on the second line to read exactly this (one long line): You are running fake ls with all your privileges - this script could remove all your files!
    3. Add a third line at the bottom of the file that is a command that can print effective userid. (The NAME line of the man page for this command says exactly that.) Hint: The command name must be one you learned in last term’s Command List, and when I say “exactly that” I mean “exactly that” not “similar to that” or “contains those words somewhere”. Exactly that.
    4. Make the new file executable if it is not already.
    5. Execute the ls script in the current directory and make sure it prints your text message on the screen, followed by your user name. Hint: To execute the ls script, you need a relative command pathname that includes a slash, as described in Search Path.

You have just finished setting a trap for anyone who has the current directory . near the beginning their PATH and runs ls while in your HOME directory.

  1. Still in your HOME directory, type the ordinary ls command name and note that you get the real ls command, because your PATH does not include the current directory. You do not have . at the start of your PATH so you didn’t run the fake ls in the current (HOME) directory.

  2. Start a subshell (a second copy of the shell).

  3. Make yourself a victim: temporarily put the current directory . at the front (start) of your current shell’s PATH variable. Hint: Review Appending to PATH, but make sure you add to the front (left) end of the PATH this time.

  4. Display the new value of your PATH variable and verify that the current directory name . is the first directory in the list, followed by a colon character (:) and the rest of the search PATH. Redirect and save this new PATH into file badpath.txt in the Base Directory.

  5. Still in your HOME directory (where the fake ls command resides), type the ls command name as you normally would. Notice that your current PATH setting (with dot at the start) means you’ve just run the fake ls command in the current directory, not the real ls command in the system directory!

    This fake ls script executes with your permissions, and it has privileges to do anything to your account that your own userid can do.

Imagine you are running as the super-user root account (not a good idea) and you have made the mistake of putting the current directory in your PATH as we have done here. (DON’T DO THIS!) Imagine further that you notice a new directory on the system that shouldn’t be there. As root you change into this directory and type ls to see what it contains. A user has placed a fake ls command in this directory. Because you’re root, that fake ls command in the current directory runs with root privileges – and it can destroy your system.


  1. Exit the subshell that has the bad PATH.

    Make sure your current shell’s PATH does not contain the current directory before you continue! Log out and back in, if needed.

Check your work so far using the check program symlink.

4.5 Creating a script

This task explores Processes and Jobs.

In this task you will create a script that prints out the number of processes each user is currently running on the system. You will create a series of scripts, each being an enhancement of the previous one, until you have the final product.

NOTE: The command that gives you a “snapshot of the current processes” has several kinds of options, some with dashes (UNIX style) and some without (BSD style), because it is really two or three commands merged into one program. You sometimes find that mixing options from the different types (with and without dashes) gives error messages. It’s best not to mix option types. See the first few paragraphs of the man page.

  1. Run a command that prints out a “full-format listing” and “select all processes” running on the system. Search in the man page for the terms “Select all processes” and “full-format” to discover the correct two UNIX-style options. (UNIX-style means the option letters must be preceded by a dash, unlike BSD-style options.) When you run the command with these two UNIX-style options, the output will be several hundred lines long, with every line starting with the userid that owns that process. The first few lines will look similar to this:

    UID        PID  PPID  C STIME TTY          TIME CMD
    root         1     0  0 Sep12 ?        00:00:11 /sbin/init
    root         2     0  0 Sep12 ?        00:00:01 [kthreadd]

    (Hint: Pipe the huge output into a command that displays only the first few lines, so you can confirm the above format.)

  2. Create a new two-line script file ps.sh in your Base Directory by copying your existing two-line myworld.sh file and replacing the second line of the new file with the process listing command you used from the previous step. Do NOT change the first line.

  3. Run the new script ps.sh to make sure it works. It should generate the full-format, all-processes listing for you, just as if you had typed it yourself on the command line.

As described in the section on awk in Data Mining, the command awk '{print $1}' reads lines from standard input and prints just the first space-delimited field of each line from that input. The output of the process listing command from your new script is conveniently in space-delimited columns.

  1. Run a command pipeline that pipes the output from your ps.sh script into an awk command line that selects just the first leading column of each line (the userid field). You should end up with a list of several hundred userids on your screen. The first three lines will be the same as the first column of the sample output given above.

  2. Copy ps.sh to ps_users.sh in the same directory.

  3. Change the second line in the new ps_users.sh file to be a command pipeline prints just the first column of the process listing. (You just did this: Add the previously-used awk command to the end of the second line in the shell script to make it a command pipeline, as you did in a previous step.) Do not change the first line.

  4. Run the new script ps_users.sh to make sure it works. It should generate a list of several hundred userids, just as if you had typed the two commands yourself on the command line.

  5. Pipe the output of your new ps_users.sh script into the sort command. The output will be the same list of several hundred userids, now in sorted order.

  6. Copy ps_users.sh to ps_sorted.sh in the same directory.

  7. Enhance the command pipeline in the new ps_sorted.sh file, adding a further pipeline into the sort command so that the one column of userids comes out sorted.

  8. Run the new script ps_sorted.sh to make sure it works. It should generate a list of several hundred userids in sorted order, just as if you had typed the three commands yourself on the command line.

  9. Pipe the output of your new ps_sorted.sh script into the command that counts adjacent identical lines.

    Instead of hundreds of lines of output, the output will be counts of the number of processes being run by each unique userid. You will see a few dozen lines of output, depending on how many users are logged in. The lines will all have this output format of a number followed by a userid, though the actual numbers and accounts may differ:

     1 102
     1 UID
     2 avahi
     1 colord
     2 cst8207a
     7 cst8207c

    Hint: There is a command that can count the number of occurrences of adjacent input lines, displaying each unique line preceded by the count of the number of times that line appeared. To recall this unique command name and its option to count adjacent lines, review the Command List from last term and the many counting Examples of pipes in Shell I/O Redirection and also in the summarizing of system log file entries in Data Mining.

  10. Copy ps_sorted.sh to ps_counted.sh.

  11. Enhance the command pipeline in the new ps_counted.sh script file to show the counts of processes run by each unique userid. (Follow the examples above on how to modify the second line of the script.)

  12. Run the new script ps_counted.sh to make sure it works. It should generate a list of more than a dozen unique userids, each preceded by a count, just as if you had typed the four commands yourself on the command line.

We can now see that there are two odd things in the output that are not account userids:

  • 102 – a number, not a userid. This appears to be a bug in the process listing program, since the passwd file does have an account entry for uid 102: messagebus
  • UID – the column heading from the first line of output of the process listing. We don’t want to see this in our output.
  1. Copy ps_counted.sh to ps_counted2.sh.

  2. Enhance the command pipeline in the new ps_counted2.sh file to eliminate the bogus UID column heading in the output.
    • The process listing command has an option to print no header line. Searching the man page for no header will find it. You will need to read about the problematic use of the single-letter option and how they solved it using long options.
  1. Run the new script ps_counted2.sh to make sure it works. It should generate a list of more than a dozen userids in sorted order, with no bogus UID in the output.

  2. Copy ps_counted2.sh to ps_counted_header.sh.

  3. Enhance the new ps_counted_header.sh script so that it prints out its own header (title) line before it generates the output. The header line should be the exact text “NumProc Username” (16 characters, including the single space, with upper-case for the N, P, and U) and you can optionally output some dashed underlining under it as well, to make the heading stand out. Line up the blank in the title with the blank in the two columns of output. The output will look similar to this, though the actual numbers and accounts may differ:

    NumProc Username
    ------- --------
          1 102
          2 avahi
          1 colord
          2 cst8207a
          7 cst8207c
    ... etc ...
  4. Run the new script ps_counted_header.sh to make sure it works. It should generate its own header line, some optional underlining, followed by a list of more than a dozen userids in sorted order, with no bogus UID in the output.

  5. The long script name ps_counted_header.sh is helpful for knowing what the script does, but it’s much too long for a command name. Make a hard link from ps_counted_header.sh to the name pch in your HOME bin directory.

  6. Because your bin directory is in your PATH, you should now be able to run pch as a command name with no slashes.

You have written your second Linux command script. Years from now, you might forget the purpose of the four commands used in the main pipeline in the script, so you must now document the script. Scripts without proper documentation (described below) are penalized heavily.

  1. Edit the ps_counted_header.sh script and add to the end of the script file four numbered comments that explain in your own words the meaning of each of the four commands used in the pipeline. Shell script comments start with the number-sign (or hash-tag) character # and extend to the end of the line. The four numbered comment lines must have a syntax similar to this (though this is the wrong pipeline and wrong comments to use for this task):

    #!/bin/sh -u
    echo "This displays the current Moon Phase"
    echo "------------------------------------"
    ee 'http://www.die.net/moon/' | fgrep -A2 'Moon Phase' | head -n 3 | tail -n 1
    # 1. ee: alias for "elinks -dump -no-numbering -no-references"
    # 2. fgrep -A2: extract lines containing "Moon Phase" and two following lines
    # 3. head -n3: keep only the first three lines
    # 4. tail -n1: keep only the last line of the above three (the moon phase)

    Since there are four commands in your script pipeline, you will need to write four numbered comment lines to explain them. As you see in the above example, each of the four comment lines starts at the left margin with the # comment character, followed by a number, a period, the pipeline command name and options to which the comment refers, and then your own comment text. Each comment text is written in your own words to explain what the command does in the pipeline. Follow the syntax shown in the above example.

Check your work so far using the check program symlink.

4.6 When you are done

That is all the tasks you need to do.

Read your CLS Linux EMail and remove any messages that may be waiting. See Reading eMail for help.

Check your work a final time using the Checking Program and save the standard output as described below. Submit your mark following the directions below.

5 Checking, Marking, and Submitting your Work

Summary: Do some tasks, then run the checking program to verify your work as you go. You can run the checking program as often as you want. When you have the best mark, upload the marks file to Blackboard.

Since I also do manual marking of student assignments, your final mark may not be the same as the mark submitted using the current version of the Checking Program. I do not guarantee that any version of the Checking Program will find all the errors in your work. Complete your assignments according to the specifications, not according to the incomplete set of the mistakes detected by the Checking Program.

  1. There is a Checking Program named assignment02check in the Source Directory on the CLS. Create a Symbolic Link to this program named check under your new Base Directory on the CLS so that you can easily run the program to check your work and assign your work a mark on the CLS. Note: You can create a symbolic link to this executable program but you do not have permission to read or copy the program file.

  2. Execute the above check program on the CLS using its symbolic link. (Review the Search Path notes if you forget how to run a program by pathname from the command line.) This program will check your work, assign you a mark, and display the output on your screen. (You may want to paginate the long output so you can read all of it.)

    You may run the check program as many times as you wish, to correct mistakes and get the best mark. Some task sections require you to finish the whole section before running the checking program at the end; you may not always be able to run the checking program successfully after every single task step.

  3. When you are done with checking this assignment, and you like what you see on your screen, redirect only the standard output of the Checking Program into the text file assignment02.txt under your Base Directory on the CLS. Use that exact name. Case (upper/lower case letters) matters. Be absolutely accurate, as if your marks depended on it.
    • Do not edit the output file. Submit it exactly as given.
    • Make sure the file actually contains the output of the checking program!
    • The file should contain near the bottom a line starting with: YOUR MARK for
  4. Transfer the above assignment02.txt file from the CLS to your local computer and verify that the file still contains all the output from the checking program. Do not edit this file! No empty files, please! Edited or damaged files will not be marked. You may want to refer to your File Transfer notes.
    • Do not edit the output file. Submit it exactly as given.
    • Make sure the file actually contains the output of the checking program!
    • The file should contain near the bottom a line starting with: YOUR MARK for
  5. Upload the assignment02.txt file from your local computer to the correct Assignment area on Blackboard (with the exact name) before the due date:
    1. On your local computer use a web browser to log in to Blackboard and go to the Blackboard page for this course.
    2. Go to the Blackboard Assignments area for the course, in the left side-bar menu, and find the current assignment.
    3. Under Assignments, click on the underlined assignment02 link for this assignment.
      1. If this is your first upload, the Upload Assignment page will open directly; skip the next sentence.
      2. If you have already uploaded previously, the Review Submission History page will be open and you must use the Start New button at the bottom of the page to get to the Upload Assignment page.
    4. On the Upload Assignment page, scroll down and beside Attach File use Browse My Computer to find and attach your assignment file from your local computer. Make sure the assignment file has the correct name on your local computer before you attach it.
    5. After you have attached the file on the Upload Assignment page, scroll down to the bottom of the page and use the Submit button to actually upload your attached assignment file to Blackboard.

    Use only Attach File on the Upload Assignment page. Do not enter any text into the Text Submission or Comments boxes on Blackboard; I do not read them. Use only the Attach File section followed by the Submit button. If you need to comment on any assignment submission, send me EMail.

    You can revise and upload the file more than once using the Start New button on the Review Submission History page to open a new Upload Assignment page. I only look at the most recent submission.

    You must upload the file with the correct name from your local computer; you cannot correct the name as you upload it to Blackboard.

  6. Verify that Blackboard has received your submission: After using the Submit button, you will see a page titled Review Submission History that will show all your uploaded submissions for this assignment. Each of your submissions is called an Attempt on this page. A drop-down list of all your attempts is available.
    1. Verify that your latest Attempt has the correct 16-character, lower-case file name under the SUBMISSION heading.
    2. The one file name must be the only thing under the SUBMISSION heading. Only the one file name is allowed.
    3. No COMMENTS heading should be visible on the page. Do not enter any comments when you upload an assignment.
    4. Save a screen capture of the Review Submission History page on your local computer, showing the single uploaded file name listed under SUBMISSION. If you want to claim that you uploaded the file and Blackboard lost it, you will need this screen capture to prove that you actually uploaded the file. (To date, Blackboard has never lost an uploaded file.)

    You will also see the Review Submission History page any time you already have an assignment attempt uploaded and you click on the underlined assignment02 link. You can use the Start New button on this page to re-upload your assignment as many times as you like.

    You cannot delete an assignment attempt, but you can always upload a new version. I only mark the latest version.

  7. Your instructor may also mark files in your directory in your CLS account after the due date. Leave everything there on the CLS. Do not delete any assignment work from the CLS until after the term is over!


| Ian! D. Allen  -  idallen@idallen.ca  -  Ottawa, Ontario, Canada
| Home Page: http://idallen.com/   Contact Improv: http://contactimprov.ca/
| College professor (Free/Libre GNU+Linux) at: http://teaching.idallen.com/
| Defend digital freedom:  http://eff.org/  and have fun:  http://fools.ca/

Plain Text - plain text version of this page in Pandoc Markdown format

Campaign for non-browser-specific HTML   Valid XHTML 1.0 Transitional   Valid CSS!   Creative Commons by nc sa 3.0   Hacker Ideals Emblem   Author Ian! D. Allen