% CST8207 Assignment 12 -- BONUS the `mkasst` utility script % Ian! D. Allen -- -- [www.idallen.com] % Winter 2017 - January to April 2017 - Updated 2017-04-13 11:55 EDT - [Course Home Page] - [Course Outline] - [All Weeks] - [Plain Text] Due Date and Deliverables ========================= > **Do not print this assignment on paper!** > > - On paper, you will miss updates, corrections, and hints added to the > online version. > - On paper, you cannot follow any of the [hyperlink URLs] that lead you > to hints and course notes relevant to answering a question. > - On paper, scrolling text boxes will be cut off and not print properly. - **Due Date**: `23:59 (11:59pm) Friday April 21, 2017 (end of Week 14)` - This is a **BONUS** assignment for extra credit. It is optional. - Late assignments or wrong file names may not be marked. Please be accurate and punctual. - **Available online** - Version 1 -- 19:00 April 12, 2017 - Version 2 -- 00:45 April 13, 2017 -- added more test examples - **Prerequisites** - All [Class Notes][hyperlink URLs] since the beginning of term. - All your previous [Assignments] and [Worksheets]. - An ability to **READ ALL THE WORDS** to work effectively. - **Deliverables** 1. One plain text file uploaded to Blackboard according to the steps in the [Checking Program] section below. 2. Use [Remote Login] to connect to the [Course Linux Server] (**CLS**) and use commands in [The Unix/Linux Shell] to create directory structure and files for marking on the **CLS**.\ **Do not delete any assignment work from the CLS until after the term is over!** **WARNING:** Some inattentive students upload Assignment #12 into the Assignment #11 upload area. Don't make that mistake! Be exact. Purpose and Background ====================== This is a **BONUS** assignment for extra credit. It is optional. This assignment is based on your weekly [Class Notes][All Weeks] and covers these topics: 1. Create a useful shell script to create assignment directories with checking program symbolic links. How to complete this Assignment =============================== For full marks, follow these directions exactly: 1. These tasks must be done in your account via [Remote Login] to the [Course Linux Server]. 2. Do the tasks in order, from top to bottom. Do not skip steps. Most tasks are independent, but some depend on successful completion of a previous task. 3. **READ ALL THE WORDS** in each task before you begin the task, especially all the **Hints**, Notes, and links. 4. Verify your own work before running the **Checking Program**. You won't have a Checking Program at your job interview and the **Checking Program** is not guaranteed to check everything. 5. Run the **Checking Program** at the end of the task to grade your work and help you find some of your errors. A perfect mark from the **Checking Program** does *not* mean your answers are correct. 6. When you are done with this Assignment, submit the output of the **Checking Program** to Blackboard before the due date, following the directions given at the end of this Assignment. This is a **BONUS** assignment for extra credit. It is optional. Notes on doing assignment work ------------------------------ 1. You can use the **Checking Program** to check your work **after** you have completed each task. Most task sections below require you to **finish the whole task section before running the Checking Program**. You may not always be able to run the **Checking Program** successfully in the middle of a task or after every single task sub-step. The assignment tells you where you can safely check your work. 2. You will create file system structure in your CLS home directory containing various directories and files. When you are finished the tasks, leave the files and directories in place on the CLS as part of your deliverables for your instructor to verify. Assignments may be re-marked at any time on the CLS; you must have your term work available on the CLS right until term end. **Do not delete any assignment work until after the term is over!** 3. You can modify your work and check it with the **Checking Program** as often as you like before you submit your final mark to Blackboard. You can upload your marks to Blackboard as many times as you like before the due date. Partial marks are accepted. 4. 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 after you have submitted your final mark to Blackboard. 5. You must keep a list of command names used each week and write down what each command does, as described in the [List of Commands You Should Know]. Without that list to remind you what command names to use, you will find future assignments very difficult. Searching the course notes on the CLS ------------------------------------- All course notes are available on the Internet and also on the CLS. You can learn about how to read and search these CLS 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]. You also learned how to search the notes in [Assignment #05 HTML]. The Source Directory -------------------- All references to the **Source Directory** below are to the CLS directory `~idallen/cst8207/17w/assignment12/` 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. Properties of all scripts ------------------------- 1. The tasks below each ask you to write an executable shell script, based on the lecture notes and slides. *None* of the scripts need complex Boolean expressions ("`||`" or "`&&`" or `-a` or `-o`); they are all scripts with simple conditional logic. 2. Each script below must begin with the Standard Script Header you used for your previous script assignments. See the class notes. 3. Make sure that each of your script files is executable, so that it can be executed as `./scriptname.sh` from the shell command line. 4. Build up each script by adding a few lines and testing what you have added; don't write the whole thing and try to debug it! 5. Run the given example tests on your scripts to make sure they work. Sample output for each of the scripts is given, so that you may check your work as you proceed. 6. Make sure your script handles *all* of the sample inputs given, especially the inputs containing shell metacharacters. (System crackers often attack your system using special characters as input.) 7. The examples below do not fully test your script; you will need to try other examples to make sure your scripts work properly for all possible inputs, especially inputs with blanks and shell meta-characters. 8. Remember to [double quote all variable expansions] to prevent GLOB and blank expansion that can cause syntax errors and other unwanted problems in your script. 9. The regular script output is on **stdout** (standard output), not **stderr** (error messages). Pay close attention to where the output should go! 10. Error messages must appear on **stderr** and follow the [Good Error Message] format given below. 11. Scripts must be documented following the rules in [Document Your Script]. 12. If you are having problems with your script and are getting error messages from the shell, review possible [Script Problems]. Tasks ===== Have you completed all the prerequisites, before attempting these tasks? 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. Create the `assignment12` directory in your usual `Assignments` directory. **This `assignment12` directory is called the [Base Directory] for most pathnames in this assignment. Store your files and answers in this [Base Directory], not in your HOME directory or anywhere else.** ### `check` 3. Create the `check` symbolic link needed to run the **Checking Program**, as you did in a previous assignment and as described in the section [Checking Program] below. **Hints:** See your previous assignment for hints on doing the above. Use the symbolic link to run the [Checking Program] to verify your work so far. ### Checking only one of your scripts Normally the [Checking Program] checks all the scripts. This can be slow if you are only interested in the check output for one script that you are working on. You can check just one or more individual scripts by giving the script names as arguments to the Checking Program: $ ./check mkasst1.sh # only check this script Do not submit for marking the output of checking only a few scripts! `mkasst1`: Making one assignment directory ------------------------------------------ Write the script developed in lecture that takes one numeric argument in the range 1 to 15 inclusive and creates a single CST8207-like assignment directory in the HOME directory of the person running the script. As shown in the lectures, the script should have full argument error-checking: only numbers from 1 through 15 should be allowed and single-digit numbers should be padded with one leading zero, e.g. `1` should be turned into `01` when you create the `assignment01` directory. Instead of using the current course and term, write the script for the fake course name DAT0000 and term 17S so that it doesn't affect your current CST8207 course. - Review [Properties of all Scripts], above. - You need to understand [Shell Scripts] and [Control Structures]. - Add comments to [Document Your Script]. **Make sure all the examples below work before you run the checking program!** Examples: $ ./mkasst1.sh ...print error message and usage message on stderr, exit non-zero... $ ./mkasst1.sh foobar ...print error message and usage message on stderr, exit non-zero... $ ./mkasst1.sh 123foo ...print error message and usage message on stderr, exit non-zero... $ ./mkasst1.sh foo123 ...print error message and usage message on stderr, exit non-zero... $ ./mkasst1.sh '' ...print error message and usage message on stderr, exit non-zero... $ ./mkasst1.sh ' ' ...print error message and usage message on stderr, exit non-zero... $ ./mkasst1.sh 123 ...print error message and usage message on stderr, exit non-zero... $ ./mkasst1.sh 0 ...print error message and usage message on stderr, exit non-zero... $ ./mkasst1.sh 16 ...print error message and usage message on stderr, exit non-zero... $ ./mkasst1.sh 1 2 ...print error message and usage message on stderr, exit non-zero... $ rm -rf ~/DAT* $ ./mkasst1.sh 1 # this works the first time $ echo $? 0 $ find ~/DAT* -name assignment01 /home/abcd0001/DAT0000-17S/Assignments/assignment01 $ ./mkasst1.sh 1 # must give an error the second time (already exists) ...print error message and usage message on stderr, exit non-zero... $ tmpdir=/tmp/test$$ $ HOME=$tmpdir ./mkasst1.sh 01 # set HOME to a temporary value and run the script $ find "$tmpdir" /tmp/test3151 /tmp/test3151/DAT0000-17S /tmp/test3151/DAT0000-17S/Assignments /tmp/test3151/DAT0000-17S/Assignments/assignment01 $ rm -r "$tmpdir" **Hints for writing this script:** I wrote most of this script for you in lecture class already. See your in-class lecture notes. All you need to do is copy it out of your notes, adjust the pathnames and argument checking a little bit, and add a Usage message. Make sure you create the new directories in the HOME directory of the user running the script. (Use the correct environment variable name.) The script must contain only one single directory creation command. Use a variable to supply the argument to the command. (As shown in class, the variable will be adjusted to have a leading zero if necessary.) Do not duplicate code. > **Hint for Testing:** You could put all the above test command lines into a > script file and run that script file to apply all the tests to your script, > one after the other, rather than repeatedly typing them all by hand every > time. (Yes, I'm saying you should write a script to test your `mkasst1.sh` > script!) If you make the first line of your testing script file include the > `-x` option, the shell will even echo each command line as it runs it for > you. Add comments to [Document Your Script]. Check your work so far using the Checking Program symlink. `mkasst2`: Making one assignment directory with check symlink ------------------------------------------------------------- Copy your working `mkasst1.sh` script to `mkasst2.sh` and modify it so that if the directory creation succeeds (good return status), also create in the new directory a symlink to an appropriate **Checking Program** for the given assignment number. The symlink you create should be named with the usual `check` name, and for its target it will need to use lower-case versions of the dummy course name DAT0000 and 17S. Do not attempt to create the symlink if the directory creation fails. If the directory creation fails, print a good error message, but not a Usage message (since the Usage must be correct), and exit non-zero. > How can you make the directory creation fail, to test that your script > generates the proper error message and exit status? Test your code! If the directory already exists, print a warning message on stderr, but instead of exiting the script, skip creating the directory (because it already exists) and go on to (re-)create the symlink inside the existing directory. Do not exit the script if the directory already exists. Use the *force* option when creating the symlink (RTFM) so that you don't get an error if the symlink already exists; with the right option, the linking command will automatically remove the old symlink before recreating it anew. This means that the script will recreate the symlink no matter whether the directory is created new, or the directory already exists. **Make sure all the examples below work before you run the checking program!** Examples: $ rm -rf ~/DAT* $ ./mkasst2.sh 1 $ find ~/DAT* -name 'check' -ls 123 0 lrwxrwxrwx 1 abcd0001 abcd0001 56 Apr 11 12:00 /home/abcd0001/DAT0000-17S/Assignments/assignment01/check -> /home/idallen/dat0000/17s/assignment01/assignment01check $ rm ~/DAT0000-17S/Assignments/assignment01/check $ ./mkasst2.sh 1 ...warning about directory assignment01 already existing... $ find ~/DAT* -name 'check' -ls 123 0 lrwxrwxrwx 1 abcd0001 abcd0001 56 Apr 11 12:01 /home/abcd0001/DAT0000-17S/Assignments/assignment01/check -> /home/idallen/dat0000/17s/assignment01/assignment01check $ tmpdir=/tmp/test$$ $ HOME=$tmpdir ./mkasst2.sh 01 # set HOME to a temporary value and run the script $ find "$tmpdir" /tmp/test3151 /tmp/test3151/DAT0000-17S /tmp/test3151/DAT0000-17S/Assignments /tmp/test3151/DAT0000-17S/Assignments/assignment01 /tmp/test3151/DAT0000-17S/Assignments/assignment01/check $ rm -r "$tmpdir" $ HOME=/ ./mkasst2.sh 01 # set HOME to a temporary value and run the script mkdir: cannot create directory `//DAT0000-17S': Permission denied ...print error message on stderr, exit non-zero... **Hints:** To make the directory creation fail so that you can test your error code, consider changing permissions, or creating files where directories should be, or setting your HOME directory variable temporarily to a directory that you cannot write (as done in the example above). > **Hint for Testing:** See the previous Hint for Testing. Write a script > that contains lines that test your script. Check your work so far using the Checking Program symlink. `mkasst3`: Making multiple assignment directories ------------------------------------------------- Copy your working `mkasst2.sh` script to `mkasst3.sh` and modify it so that it loops and makes *all* the directories and symlinks given by *all* the arguments on the command line. The script must allow multiple directory numbers as arguments and create them all and put in all the correct symlinks to the correct checking programs. This new script is a modification of your previous script. It keeps all of the argument error checking, but does not exit when it detects an error; it prints an error message and loops back to get the next command line argument. The shell has a loop modifier control word that skips back to the top of a loop. If any of the command line arguments is not a valid number, print only an error message on stderr for that argument (do not print a Usage message) and skip that argument and keep going (making the other directories, if any), but make sure when the script finally exits that it exits with a non-zero status (indicating there was an error in at least one argument) and it prints the Usage message once on stderr. The script must not exit until *all* the arguments are processed. If there were any errors in any of the arguments, after processing all the arguments the script will print a single Usage message and exit non-zero. If everything worked, the script exits silently (no output) with a good return status. Multiple argument errors must generate only *one* Usage message, just before the script exits. **Make sure all the examples below work before you run the checking program!** Examples: $ ./mkasst3.sh # no arguments is an error ...print error message and usage message on stderr, exit non-zero... $ rm -rf ~/DAT* $ ./mkasst3.sh 1 2 14 15 # four valid assignment numbers $ find ~/DAT* -name 'check' /home/abcd0001/DAT0000-17S/Assignments/assignment01/check /home/abcd0001/DAT0000-17S/Assignments/assignment02/check /home/abcd0001/DAT0000-17S/Assignments/assignment14/check /home/abcd0001/DAT0000-17S/Assignments/assignment15/check $ rm -rf ~/DAT* $ ./mkasst3.sh 1 crap 2 999 3 0 4 # three invalid arguments ...print single error message about 'crap' on stderr... ...print single error message about '999' on stderr... ...print single error message about '0' on stderr... ...print Usage message on stderr (once!) and exit non-zero... $ echo $? 1 $ find ~/DAT* -name 'check' /home/abcd0001/DAT0000-17S/Assignments/assignment01/check /home/abcd0001/DAT0000-17S/Assignments/assignment02/check /home/abcd0001/DAT0000-17S/Assignments/assignment03/check /home/abcd0001/DAT0000-17S/Assignments/assignment04/check $ find ~/DAT* -name 'check' -delete # delete just the check symlinkks $ ./mkasst3.sh 1 2 3 4 # all these directories already exist ...warning about directory assignment01 already existing... ...warning about directory assignment02 already existing... ...warning about directory assignment03 already existing... ...warning about directory assignment04 already existing... $ find ~/DAT* -name 'check' /home/abcd0001/DAT0000-17S/Assignments/assignment01/check /home/abcd0001/DAT0000-17S/Assignments/assignment02/check /home/abcd0001/DAT0000-17S/Assignments/assignment03/check /home/abcd0001/DAT0000-17S/Assignments/assignment04/check You do not need to print a Usage message if you only printed warning messages about existing directories. (Obviously the user of the script knows how to use it!) As with the previous version of this script, the symlink is created whether the directory is created new or whether the directory already exists. An existing directory produces a warning message on stderr and the symlink is re-created in the directory. As with the previous script, do not attempt to create the symlink if creating a new directory fails. Print an error message on stderr and go back to the top of the loop to try the next command line argument (if any). **Hints:** You need to understand shell script [Control Structures]. 1. Instead of processing just the first argument `$1`, your new script must iterate over each command line argument. The shell can do this easily with a [loop control structure] that sets a variable to be each argument in turn. You will need to edit your script code to use that variable name instead of `$1` everywhere. 2. Do not exit the script when an argument is invalid; print an error message (not a Usage message) and keep going to the next argument. The shell has a [loop modifier control word] that skips back to the top of a loop (to get the next argument). 3. When the script encounters an error, set a variable to indicate that an error occurred and check the value of that variable at the end of the script to know whether to exit with a good return status or to exit with a non-zero return status and a Usage message on stderr. For example, set the variable to zero at the start of the script and set it to one after any error. At the end of the script, after all the arguments have been processed and all the error messages printed, test to see if the variable is still zero and do the right thing. 4. The Usage message should only print once, if there was an error in any of the arguments, and only after all the arguments are processed. Use the variable trick above to decide whether or not any errors occurred in the arguments. Do not print the Usage message if there were no errors in any of the command line arguments. 5. You will need to modify your argument count checking code to allow more than one argument to the script. Read All The Words. Check your work so far using the Checking Program symlink. `mkasst` symbolic link ---------------------- You need to understand [Symbolic Links], [Shell Variables], and [Search Path] to do this task. Make sure you have a personal `bin/` directory in your account. (You created this directory in a previous assignment.) Make sure your personal `bin/` directory is added to the end of your search path every time you log in. (You did this in a previous assignment.) 1. Use a [relative symlink] to link the `mkasst3.sh` script into your personal `bin/` directory under the name `mkasst`. Execute the `mkasst` program using this name in the `bin/` directory to make sure the relative symlink works. 2. Make sure you can type `mkasst` into the shell and have your shell find and run your script from in your `bin/` directory using your modified (at login) search path. **Hints:** Please Read All The Words in the sentence that begins with the words "Use a" above, especially the word that begins with the letter "r". Check your work so far using the Checking Program symlink. 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] below and save the standard output of that program into a file as described below. Submit that file (and only that one file) to Blackboard following the directions below. When you are done, log out of the CLS before you close your laptop or close the PuTTY window, by using the shell `exit` command: $ exit Document Your Script ==================== You must document your script with comment lines before you submit it. Script comment lines start with the comment or *hashtag* character `#` and extend to the end of the line. You can (and must) use more than one comment line in your script. Add at least five (or more) comment lines to each script containing the following five types of information, in the following order: 1. The assignment number and name (copied exactly from the top of the assignment page). 2. The question number and script name, e.g. `4.2 mkasst1.sh` 3. Your name, your 9-digit student number, and your Algonquin email address. 4. The one-line Signing Key for this script file, generated by running the Checking Program with a first argument of `-s` and a second argument of the script name, e.g. `./check -s mkasst1.sh` The Signing Key comment line must start with `# KEY:` and will be about 89 characters long. 5. A brief summary in your own words of what the script does. The summary can be one or more comment lines long. The comments will be read and marked by your professor after you have submitted your lab; the Checking Program cannot evaluate the quality of what you write. Poor comments means poor marks. Obey these rules for your script comments: 1. Use your own words to *describe* your script; don't copy mine. Your description might document any special features that are worth noting and remembering, such as the use of `1>&2` to write messages to standard error instead of standard output. 2. The block of five or more comment lines must appear below the standard script header and above your actual script code. 3. A blank line must separate the block of comment lines from the script header above it and another blank line must separate the block of comments from the script code below it. 4. Each comment line except the `KEY` line should be **less than 80 characters long**, to fit on a standard terminal screen nicely. Use multiple comment lines starting with `#` rather than making one huge long comment line. (The VIM text editor shows your line and column number in the bottom right of your screen.) 5. The comments will be read and marked by your professor after you have submitted your lab; the Checking Program cannot evaluate the quality of the documentation that you write. Poor comments means poor marks. Here is a sample comment block for a hypothetical assignment number 99: # Assignment 99 This is a Sample Comment Block # 1.2 foo.sh # Ian Allen 123456789 abcd0001@algonquinlive.com # KEY: foo.sh ==w/XdTMtcDMygDVTN0/zADMx8vY3AjM4Q3cj9Paz5ycnJXY39Gaz9PNwMzM4MDM5QTMV # This is a script that demonstrates how to frob the widjet. # If there are no widjets to frob, the script prints an # error message end exits with status 2. Otherwise exit zero. Make sure you do the correct placement of the comment block in the script file, as described above! The comments will be read and marked by your professor after you have submitted your lab; the Checking Program cannot evaluate the quality of the documentation that you write. Poor comments means poor marks. Good Error Messages and Usage Messages ====================================== Good shell script error messages must obey these four rules: 1. Error messages must appear on standard error, not standard output. You can use the shell syntax `1>&2` to send to **stderr** any output normally destined for **stdout**. See the examples below. - Usually `1>&2` is used on `echo` statements, to send the text to standard error instead of standard output. 2. Must contain the name of the program that is issuing the message (from `$0`). - Do not put the name of the script into the script (except in the submission comment and `KEY` lines); always use `$0`. 3. Must state what kind of input was expected (e.g. `expecting one file name`). - Do not say only "expecting one argument", since that doesn't say what *kind* of argument is needed. Be explicit about what is expected. Avoid using only the vague word "argument". 4. Must display what input the user actually entered (e.g. `found 3 (a b c)` - Display both the number of arguments `$#` and their values `$*`. *Never* say just `missing argument` or `illegal input` or `invalid input` or `too many`. Always specify exactly what is needed and how many is "too many" or "too few". Here are examples: echo 1>&2 "$0: Expecting 3 file names; found $# ($*)" echo 1>&2 "$0: Student age '$student_age' is not between $min_age and $max_age" echo 1>&2 "$0: Modify days '$moddays' must be greater than zero" echo 1>&2 "$0: File '$file' does not exist; expecting accounting file" Put quotes around anything entered by a user, otherwise your error messages may be confusing. Compare these example messages without and with quotes around the user input file name: $ ./total.sh still ./total.sh: File still does not exist; expecting accounting file Usage: ./total.sh account_file $ ./total.sh still ./total.sh: File 'still' does not exist; expecting accounting file Usage: ./total.sh account_file The quotes make it clearer that `still` is a file name, not an adverb. The Usage Message ----------------- After detecting an error, the usual thing to do is print a **Good Error Message** explaining the error, followed by a **Usage** message telling how to use the script, then exit the script with a non-zero return code. Don't keep processing bad data! The **Usage** message gives the syntax for correctly using the script, using `man` page syntax to indicate optional and repeated arguments, e.g.: Usage: ./script.sh [ first_line [ last_line ] ] Usage: ./script.sh filename... The name of the script is output using the `$0` variable. Do not hard-code the name of a script inside the script (except in the submission comment and `KEY` lines). 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 single file that is the output of the **Checking Program** 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**. ### `check` 1. There is a **Checking Program** named `assignment12check` in the [Source Directory] on the CLS. You can execute this program by typing its (long) pathname into the shell as a command name and paginating the (often long) output using `less`: $ ~idallen/cst8207/17w/assignment12/assignment12check | less Create a symbolic link named `check` in your [Base Directory] that links to the [Checking Program] in the [Source Directory], as you did in a previous assignment. Use the symlink to check your work: $ ./check | less > Checking only one of your scripts > --------------------------------- > > Normally the [Checking Program] checks all the scripts. This can be slow if > you are only interested in the check output for one script that you are > working on. You can check just one or more individual scripts by giving the > script names as arguments to the Checking Program: > > $ ./check mkasst1.sh # only check this script > > Do not submit for marking the output of checking only a few scripts! 2. When you are done, execute the above **Checking Program** as a command line on the CLS. This program will check your work, assign you a mark, and display the output on your screen. You may run the **Checking Program** as many times as you wish, allowing you 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 this assignment, and you like the mark displayed on your screen by the **Checking Program**, you must **redirect** only the standard output of the **Checking Program** into the text file `assignment12.txt` in your [Base Directory] on the CLS, like this: $ ./check >assignment12.txt $ less assignment12.txt - Use standard output redirection with that *exact* `assignment12.txt` file name. - 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; the format is fixed. - 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` - Really! **MAKE SURE THE FILE HAS YOUR MARKS IN IT!** 4. Transfer the above single file `assignment12.txt` (containing the output from the **Checking Program**) from the CLS to your local computer. - You may want to refer to the [File Transfer] page for how to transfer the file. - Verify that the file still contains all the output from the **Checking Program**. - Do not edit or open and save this file on your local computer! Edited or damaged files will not be marked. Submit the file exactly as given. - The file should contain, near the bottom, a line starting with: `YOUR MARK for` - Really! **MAKE SURE THE FILE YOU UPLOAD HAS YOUR MARKS IN IT!** 5. Upload the `assignment12.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 **assignment12** link for this assignment. a) If this is your first upload, the *Upload Assignment* page will open directly; skip the next sentence. b) 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 `assignment12.txt` file from your local computer. Make sure the assignment file has the correct name on your local computer before you attach it. Attach *only* your `assignment12.txt` file for upload. Do not attach any other file names. 5. After you have attached the `assignment12.txt` file on the *Upload Assignment* page, scroll down to the bottom of the page and use the *Submit* button to actually upload your attached `assignment12.txt` file to Blackboard. 6. Submit the file exactly as uploaded from the CLS. 7. Do not submit an empty file. Do not submit any other file names. Use only *Attach File, Browse My Computer* on the *Upload Assignment* page. Do not enter any text into the *Write Submission* or *Add Comments* boxes on Blackboard; I do not read them. Use only the *Attach File, Browse My Computer* 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. **Make sure the file name on Blackboard is correct!** 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. a) Verify that your latest *Attempt* has the correct 16-character, lower-case file name under the *SUBMISSION* heading. b) The one file name must be the *only* thing under the *SUBMISSION* heading. Only the one file name is allowed. c) No *COMMENTS* heading should be visible on the page. Do not enter any comments when you upload an assignment. d) Click on the *Download* button to open and view the file you just uploaded. **MAKE SURE THE FILE YOU JUST UPLOADED HAS YOUR MARKS IN IT!** e) **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.) f) Make sure you have used *Submit* and not *Save as Draft*. I cannot mark draft assignments. Make sure you *Submit*. You will also see the *Review Submission History* page any time you already have an assignment attempt uploaded and you click on the underlined **assignment12** 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!** - I do not accept any assignment submissions by EMail. Use only the Blackboard *Attach File, Browse My Computer*. No word processor documents. Plain Text only. - Use the *exact* file name given above. Upload only one single file of Linux-format plain text, not HTML, not RTF, not MSWord. No fonts, no word-processing. Linux plain text only. - **NO EMAIL, WORD PROCESSOR, PDF, RTF, or HTML DOCUMENTS ACCEPTED.** - No marks are awarded for submitting under the wrong assignment number or for using the wrong file name. Use the exact 16-character, lower-case name given above. - **WARNING:** Some inattentive students don't Read All The Words. Don't make that mistake! Be exact. **READ ALL THE WORDS. OH PLEASE, PLEASE, PLEASE READ ALL THE WORDS!** ![[Parents: Talk to your kids about Linux]][1] -- | Ian! D. Allen, BA, MMath - 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 [www.idallen.com]: http://www.idallen.com/ [Course Home Page]: .. [Course Outline]: course_outline.pdf [All Weeks]: indexcgi.cgi [Plain Text]: assignment12.txt [hyperlink URLs]: indexcgi.cgi#Important_Notes__alphabetical_order_ [Assignments]: indexcgi.cgi#Assignments [Worksheets]: indexcgi.cgi#Worksheets__not_for_hand_in_ [Checking Program]: #checking-marking-and-submitting-your-work [Remote Login]: 110_remote_login.html [Course Linux Server]: 070_course_linux_server.html [The Unix/Linux Shell]: 120_shell_basics.html [List of Commands You Should Know]: 900_unix_command_list.html [Assignment #05 HTML]: assignment05.html [double quote all variable expansions]: 440_quotes.html#double-quote-all-variable-expansions [Good Error Message]: #good-error-messages-and-usage-messages [Document Your Script]: #document-your-script [Script Problems]: 740_script_problems.html [Base Directory]: #set-up-the-base-directory-on-the-cls [Properties of all Scripts]: #properties-of-all-scripts [Shell Scripts]: 700_shell_scripts.html [Control Structures]: 730_control_statements.html [loop control structure]: 730_control_statements.html#the-for-do-done-loop-statement [loop modifier control word]: 730_control_statements.html#loop-modifiers-break-and-continue [Symbolic Links]: 460_symbolic_links.html [Shell Variables]: 320_shell_variables.html [Search Path]: 400_search_path.html [relative symlink]: 460_symbolic_links.html#dereferencing-relative-path-symlinks [Reading EMail]: 070_course_linux_server.html#email-on-the-cls [Source Directory]: #the-source-directory [File Transfer]: 015_file_transfer.html [EMail]: mailto:idallen@idallen.ca [Parents: Talk to your kids about Linux]: http://xkcd.com/456 [1]: http://imgs.xkcd.com/comics/cautionary.png "Parents: Talk to your kids about Linux" [Pandoc Markdown]: http://johnmacfarlane.net/pandoc/