% CST8207 Assignment 12 -- Shell Script Parameters and Control Flow % Ian! D. Allen -- -- [www.idallen.com] % Fall 2018 - September to December 2018 - Updated 2019-03-12 17:02 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**: `09h00 (9am) Monday December 10, 2018 (start of Week 14)` - This is your last official assignment. - Late assignments or wrong file names may not be marked. Please be accurate and punctual. - **Available online** - Version 1 -- 01:00 November 24, 2018 - Version 2 -- 14:15 December 5, 2018 -- new due date; see above - **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 Brightspace 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 assignment is based on your weekly [Class Notes][All Weeks] and covers these topics: 1. Create shell scripts that deal with parameters and flow control. 2. Practice with a Linux text editor. 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 Brightspace before the due date, following the directions given at the end of this Assignment. 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 Brightspace. You can upload your marks to Brightspace 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 Brightspace. 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/18f/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. Most of the tasks below ask you to write a small 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 simple scripts with simple conditional logic. 2. Each script below must begin with the Standard Script Header. See the class notes. 3. Though some of the Standard Script Header is executable code, in the descriptions below we don't count those lines, or any comment or blank lines, in the size of the script. We only count the *new* lines of executable code that you write. > For example, a "one-line script" is really several lines of header, a blank > line, a block of several comment lines that [Document Your Script], another > blank line, and then your **one line** of actual script code. The > description below calls this a *one line script*, even though it may > contain a dozen lines. 4. Make sure that each of your script files is executable, so that it can be executed as `./scriptname.sh` from the shell command line. 5. 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! 6. 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. 7. 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.) 8. 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. 9. 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. 10. The regular script output must be on **stdout** (standard output), not on **stderr** (which is for error messages). Pay close attention to where the output should go! 11. Error messages must appear on **stderr** and follow the format given in [Good Error Messages]. 12. Scripts must be documented following the rules in [Document Your Script]. **No documentation means no marks.** 13. If you are having problems with your script and are getting error messages from the shell, review [Shell Script Debugging] and [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 assignments 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 homeWeb.sh # only check this script $ ./check thereIs.sh isExec.sh # only check these two scripts Do not submit for marking the output of checking only a few scripts! Basic Scripts ------------- These basic scripts deal with command line arguments. The concepts here will be used in the next section. Review [Properties of all Scripts], above, especially if you encounter problems with your script. ### `homeWeb.sh` Topics: **Arguments and conditional statements `if then else`, and `test`:** You need to understand [Shell Variables], [Shell Scripts] and [Control Structures] to do this script. Create a script named `homeWeb.sh` that fetches the Course Home page URL `http://teaching.idallen.com/cst8207/18f/` from the Internet, formats it, and searches for an optional text string and one line of surrounding context in the formatted page. If no search string is given, search for the default text string: `Final exam` The script must have exactly the following control statement structure and use correct shell `if then else` statements: # Follow this structure (2 IF statements, 2 ELSE) for your script. # The last line will be the elinks pipeline that does the actual work. IF the number of arguments is zero, THEN SET a variable to be the default text string ELSE IF the number of arguments is one, THEN SET the same variable to be the first (only) argument ELSE PRINT a Good Error Message (see notes above) on stderr PRINT a Usage Message (how to use this script) on stderr EXIT the script with a status value of 2 (failure) ENDIF ENDIF FETCH the formatted web page and SEARCH for the text in the variable **How to approach writing this script:**\ See also the **Hints** below. I suggest you start by writing a one-line script (no control structure) that searches for a fixed text string (e.g. use the default string `Final exam`) and get that one-line script working -- this would be similar to the last line of the script structure above. Once the one-line script is working, add the first `if` statement that sets a variable, and search using the text in the variable instead of the fixed text string. Once that is working, add the second `if` statement inside the first. **Do not write a dozen lines of shell script and expect it to work.** Write one or two lines at a time and test after each added line. **Hints:** *(Read All The Words!)* 1. Review [Properties of all Scripts], above. 2. Use a single `elinks` command with three options from the [Redirection - Using `elinks`] course notes page to fetch the URL and format the web page. (Use the command and options spelled out in full; do not use an alias inside a shell script. Aliases are for humans, not for scripts.) 3. As shown in the [Redirection - using `elinks`] page, send the output of `elinks` into a text search program. Use the value of the script variable as the text to search for. The text string must be searched for literally; it is not a pattern or regular expression. Use the correct searching command name that you've been using all term. 4. The text search program should use the `--context` option to print one line of context before and after the search text (if found). (RTFM) 5. As shown in the control statement structure above, your script must use the `elinks` command pipeline exactly once at the end of the script. Do not duplicate code. The `elinks` command is used only once; a variable is set earlier in the script to give the command the correct string to search for. See a similar use of a variable in [Nested Control Structures]. 6. GLOB characters must *not* expand when passed into the script as arguments and processed by the script. 7. You are allowed/encouraged to use `elif` to simplify the nested `if` statements and use less code indenting. See [Nested Control Structures]. 8. Do not use shell *aliases* inside scripts. Aliases are for humans. 9. Do not use any conditional operators such as `&&` or `||`. 10. Follow the control statement structure exactly as given above. 11. For full marks, indent the statements in the script correctly. **Make sure all the examples below work before you run the Checking Program!** Examples: $ ./homeWeb.sh after 2018-12-15. 2018-12-13 – Week 15 – Thursday December 13 8am–11am – GYM – Final exam (3 hours – 40%) $ ./homeWeb.sh 'Thanksgiving' your first class and to all your classes. 2018-10-08 – Week 6 – Monday October 8 – Thanksgiving Day (College closed) $ ./homeWeb.sh 'Course Evaluation Closes' (3 hours – 40%) 2018-12-16 – Week 15 – Sunday December 16 – Course Evaluation Closes 2019-01-07 – Week 1 – Monday January 7 – start of Winter Term 2019 $ ./homeWeb.sh '*' ...should output dozens of lines containing *... $ ./homeWeb.sh too many args ...your own Error message prints here... ...your own Usage message prints here... $ ./homeWeb.sh '-known' Students learn the basic concepts and features of the GNU/Linux operating system and utilities, the world's most well-known Free/Libre Open Source Software (FLOSS) project and the underlying technology Notes (Read All The Words): 1. Review [Properties of all Scripts], above. 2. The successful output is almost always exactly three lines: one line of text found by the text search program and one line of context before and one line of context after that line. 3. Follow the directions in [Good Error Messages] for writing your own Error and Usage messages. Use your own words. Make the messages helpful. 4. Your script probably fails with an error message if passed a search string starting with a leading hyphen, e.g. try searching for `-known`. If you RTFM under "Matching Control" in the search command, you can find an option to *protect the pattern* and eliminate the error message. Add comments to [Document Your Script]. Check your work so far using the Checking Program symlink. Path checking scripts --------------------- These path checking scripts use concepts from the Basic Scripts you have written and add error checking and conditional logic. You may find it useful to copy and adapt some of your working code from the Basic Scripts you have written in this course. Review [Properties of all Scripts], above, especially if you encounter problems with your script. ### `thereIs.sh` Topics: **Arguments and conditional statements `if then else`, and `test`:** You need to understand [Shell Scripts] and [Control Structures] to do this. Combine the concepts from the previous scripts and add argument validation. Create a script named `thereIs.sh` that outputs a line saying whether an argument pathname (any kind of pathname) exists or not. The pathname will be passed to the script as the only argument to the script. The script must ensure that exactly one argument is supplied, and that the argument is not the empty string. If anything is wrong, the script will issue an Error and Usage message in the format given in [Good Error Messages] and exit with a status of `2`. The script must have exactly the following control statement structure and use full `if then else` statements and *not* inline conditional operators such as `||` or `&&`: # Follow this exact structure (3 IF statements, 1 ELSE) for your script: IF the number of arguments is not 1, THEN PRINT a Good Error Message (see notes) on stderr PRINT a Usage Message (how to use this script) on stderr EXIT the script with a status 2 ENDIF IF the argument is empty (empty string ""), THEN PRINT a Good Error Message (see notes) on stderr PRINT a Usage Message (how to use this script) on stderr EXIT the script with status 2 ENDIF IF the argument is a pathname that exists, THEN PRINT a statement saying that the pathname 'xxx' exists EXIT the script with status 0 ELSE PRINT a statement saying that the pathname 'xxx' doesn't exist EXIT the script with status 1 ENDIF where `xxx` is whatever argument the user supplied on the command line. (Make sure the script outputs the quoted name of the pathname somewhere in the output message.) The script must exit with a status of: 0. Status of `0` if the pathname exists. 1. Status of `1` if the pathname does not exist. 2. Status of `2` if the number of arguments is not 1, or, if the one argument pathname is the empty string. The examples below do not show the correct message output from the script. You must write your own error messages and Usage messages according to the [Good Error Messages] rules, and you must choose what to say if the pathname does exist. (Remember to output the quoted pathname!) **Make sure all the examples below work before you run the Checking Program!** Examples: $ ./thereIs.sh >out ...error message about wrong number of arguments prints here... ...usage message prints here... $ echo $? 2 $ ./thereIs.sh a '*' c >out ...error message about wrong number of arguments prints here... ...usage message prints here... $ echo $? 2 $ ./thereIs.sh "" >out ...error message about empty argument prints here... ...usage message prints here... $ echo $? 2 $ ./thereIs.sh thereIs.sh ...some message saying that the supplied pathname exists... $ echo $? 0 $ ./thereIs.sh .. ...some message saying that the supplied pathname exists... $ echo $? 0 $ ./thereIs.sh /dev/null ...some message saying that the supplied pathname exists... $ echo $? 0 $ ./thereIs.sh /dev/sda ...some message saying that the supplied pathname exists... $ echo $? 0 $ ./thereIs.sh /dev/log ...some message saying that the supplied pathname exists... $ echo $? 0 $ ./thereIs.sh nosuchfile ...some message saying that the supplied pathname does not exist... $ echo $? 1 $ ./thereIs.sh '*' >out $ echo $? 1 $ cat out ...some message saying that the supplied pathname does not exist... Notes and **Hints:** 1. Review [Properties of all Scripts], above. 2. GLOB characters given as arguments must *not* expand when processed by the script. 3. Each one of the [Good Error Messages] explains clearly what the error is and is followed by a Usage message. 4. The error message text must use words relevant to this script. Don't say vague and unhelpful things such as `missing argument`. Add comments to [Document Your Script]. Check your work so far using the Checking Program symlink. ### `isExec.sh` Topics: **Arguments and loop statement `if then else`, `test`, and `for`:** You need to understand [Shell Scripts] and [Control Structures] to do this. Create a script named `isExec.sh` that loops over one or more pathname arguments. (Print a good error message and exit with status 2 if there are no arguments.) For each argument, print a message if the argument is inaccessible or non-existent, otherwise print a message if the pathname is not executable. Print nothing if the pathname is executable. The script must have exactly the following control statement structure and use full `if then else` statements and not conditional operators such as `&&`: # Follow this structure (3 IF statements, 1 FOR loop) for your script: IF the number of arguments is zero, THEN PRINT a Good Error Message (see notes) on stderr PRINT a Usage Message (how to use this script) on stderr EXIT the script with a status 2 ENDIF FOR each argument on the command line IF the argument does not exist, THEN PRINT your own message about it being inaccessible or nonexistent ELSE IF the argument is not executable, THEN PRINT your own message about the pathname being not executable ENDIF ENDIF ENDFOR Notes and **Hints:** 1. Review [Properties of all Scripts], above. 2. Copy the relevant parts of the example from Control Statements [The FOR Loop] to get the correct syntax to loop over all command line arguments and test for executablility. You will need to add a preceding test for pathname existence, as shown above. 3. You may combine the `else` followed immediately by `if` into an `elif` statement, as shown in [Condensing IF ELSE][Nested Control Structures] 4. The standard output messages must display the pathname at the end of the message. (Display what the user typed in.) 5. The error messages must use words relevant to this script. Don't say vague and unhelpful things such as `missing argument`. The examples below do not show all the correct message output from the script. You must write your own Error messages and Usage messages according to the [Good Error Messages] rules. **Make sure all the examples below work before you run the Checking Program!** Examples: $ ./isExec.sh >out ...your own Error message about having missing arguments prints here... ...your own Usage message should print here... $ echo $? 2 $ wc out 0 0 0 out $ ./isExec.sh nosuchfile >out $ cat out ...some kind of message about pathname inaccessible or nonexistent: nosuchfile $ ./isExec.sh /etc/passwd /etc/group ...some kind of message about it not being executable: /etc/passwd ...some kind of message about it not being executable: /etc/group $ ./isExec.sh /etc/* | wc -l 130 # exact number may differ slightly $ ./isExec.sh /usr/sbin/* | wc -l 1 # exact number may differ slightly $ mkdir -p a/b $ chmod a-x a $ ./isExec.sh a/b >out $ cat out ...some kind of message about pathname inaccessible or nonexistent: a/b Add comments to [Document Your Script]. Check your work so far using the Checking Program symlink. ### `symType.sh` Topics: **Arguments and conditional statements `if then else`, `test`, and `case`:** You need to understand [Command Substitution], [Shell Scripts], and [Control Structures] to do this. Create a script named `symType.sh` that accepts a single pathname argument that must be a symlink and classifies the symlink target according to whether it points to an absolute or to a relative pathname target. The script must have exactly the following control statement structure and use full `if then else` statements and *not* conditional operators such as `||` or `&&`: # Follow this exact structure (4 IF statements, 1 CASE) for your script: IF the number of arguments is not 1, THEN PRINT a Good Error Message (see notes) on stderr PRINT a Usage Message (how to use this script) on stderr EXIT the script with a status 2 ENDIF IF the argument is empty (empty string ""), THEN PRINT a Good Error Message (see notes) on stderr PRINT a Usage Message (how to use this script) on stderr EXIT the script with status 2 ENDIF # See the Notes below for a way to do this next symbolic link test: IF the argument is a not an existing symbolic link, THEN PRINT an Error Message (on stderr) saying that the pathname 'xxx' is not a symlink PRINT a Usage Message (how to use this script) on stderr EXIT the script with status 2 ENDIF GENERATE a long listing of the pathname argument and EXTRACT the last (rightmost) field of the output (the symbolic link target to the right of ->). SAVE that symlink target output in a shell variable. See the Notes below for hints. # We need to make sure the listing worked and exit if it failed: IF the shell variable content is empty (empty string ""), THEN PRINT a Good Error Message (see notes) on stderr EXIT the script with status 3 ENDIF Use a CASE statement to CLASSIFY the symlink target (in the variable) according to whether it is Absolute or Relative and SET another classify variable to be used in a later echo statement. See the Notes for hints on how to do this. Finally, PRINT one of these two exact messages on standard output: Absolute symlink: 'xxx' -> 'target' Relative symlink: 'xxx' -> 'target' The `xxx` above is whatever argument the user supplied on the command line. The `target` above is the symlink target from inside the variable. The messages must be worded and punctuated *exactly* as shown above and in the example output below. **EXACTLY!** Only one of the above messages should be output, and the message must be worded and punctuated *exactly* as shown above. The message will use the classify variable set in the CASE statement. Notes and **Hints:** 1. Review [Properties of all Scripts], above. 2. The `test` command has a file operator to test for a symbolic link. RTFM. 3. Review the [Selecting Fields] program `awk` that can extract just the last field of a line piped to it on standard input. 4. Review [Command Substitution] for how to save the output of a command pipeline into a variable. 5. Copy the relevant parts of the example from Control Statements [Case Statements] to get the correct syntax to classify a pathname using a `case` statement with a GLOB pattern and set a variable. 6. The error messages must use words relevant to this script. Don't say vague and unhelpful things such as `missing argument`. The examples below do not show all the correct message outputs from the script. You must write your own error messages and Usage messages according to the [Good Error Messages] rules. **Make sure all the examples below work before you run the Checking Program!** Examples: $ ./symType.sh >out ...error message about wrong number of arguments prints here... ...usage message prints here... $ echo $? 2 $ wc out 0 0 0 out $ ./symType.sh a '*' c >out ...error message about wrong number of arguments prints here... ...usage message prints here... $ echo $? 2 $ wc out 0 0 0 out $ ./symType.sh "" >out ...error message about empty argument prints here... ...usage message prints here... $ echo $? 2 $ wc out 0 0 0 out $ ./symType.sh /etc/passwd >out ...error message about not being a symbolic link prints here... ...usage message prints here... $ echo $? 2 $ wc out 0 0 0 out $ ./symType.sh '*' >out ...error message about not being a symbolic link prints here... ...usage message prints here... $ echo $? 2 $ wc out 0 0 0 out $ ./symType.sh /bin/sh Relative symlink: '/bin/sh' -> 'dash' $ echo $? 0 $ ./symType.sh /usr/bin/vi Absolute symlink: '/usr/bin/vi' -> '/etc/alternatives/vi' $ echo $? 0 **Note that the standard output of the script must be one of two lines, and each those lines must be spelled and appear *exactly* as shown above.** Add comments to [Document Your Script]. Check your work so far using the Checking Program symlink. ### `symType` 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 `symType.sh` script into your personal `bin/` directory under the name `symtype` (lower case). Execute the `symtype` program using this name in the `bin/` directory to make sure the relative symlink works. 2. Make sure you can type `symtype` into the shell and have your shell find and run your script from in your `bin/` directory using your 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 Brightspace following the directions below. Your instructor will also mark the [Base Directory] in your account on the due date. Leave everything there on the CLS. Do not delete anything. 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. Comments on 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, i.e. `CST8207 Assignment 12 Shell Script Parameters and Control Flow`). 2. The question number and script name, e.g. `4.2.1 homeWeb.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 as you did in **Part A** of [Assignment #09 HTML], e.g. `./check -s homeWeb.sh` The Signing Key comment line must start with `# KEY:` and will be about 80-90 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. 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.3 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. Academic Honesty Declaration comments ------------------------------------- There is no group work in this course. Because of the large number of students who shared, copied, and worked together on scripts in previous terms and who were all charged with Academic Dishonesty during Exam Week, you must now declare that you are the sole author of your script. You must write your own script. Type the text from the [Academic Honesty Declaration] into the end (bottom) of every script using comment lines. Use as many (or few) comment lines as you wish, but keep the length of your lines less than 80 characters each. The number of words on each line doesn't matter as long as you type all the text as comments. You must type these comment lines yourself; do not copy them from anywhere else. If your script is found to have text in common with any other people, you will be charged with Academic Dishonesty ([AA18]) or Plagiarism ([AA20]) in the middle of your Exam Week, and your course marks may be delayed and downgraded. An Academic Discipline hearing is highly disruptive to your Exam Week. Do your own assignments; do not copy. 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 Brightspace. > 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. Create a symbolic link named `check` in your [Base Directory] that links to the above [Checking Program] in the [Source Directory], as you did in a previous assignment. 2. Execute the above **Checking Program** as a command line on the CLS. The checking program will check your work, assign you a mark, and display the output on your screen: $ ./check | less You may run the **Checking Program** as many times as you wish, allowing you to correct mistakes and get the best assignment 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.** > 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 homeWeb.sh # only check this script > $ ./check thereIs.sh isExec.sh # only check these two scripts > > Do not submit for marking the output of checking only a few scripts! 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 - 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. You can view the output file one-page-at-a-time using the `less` program (use the space bar to page forward and use the letter `q` to quit): $ less assignment12.txt - In `less` use the space bar to page forward and use the letter `q` to quit). - 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. - 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 single `assignment12.txt` file from your local computer to the correct **A-12 Assignment #12** area on Brightspace before the due date: - See [Assignment #01] for details on how to upload files to Brightspace. - Only upload the one file that is the standard output of the [Checking Program]. - Make sure the file has the correct `assignment12.txt` name. - Make sure you upload it to the right place, *not* into Assignment 8 or 7! 6. 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!** Notes: - I do not accept any assignment submissions by EMail. Use only the Brightspace *Upload* and *Submit* method. - Use the *exact* file name given above. Upload only one single file of output from the **Checking Program**. - 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 [Document Your Script]: #document-your-script [double quote all variable expansions]: 440_quotes.html#double-quote-all-variable-expansions [Good Error Messages]: 735_good_error_messages.html [Shell Script Debugging]: 725_debugging_shell_scripts.html [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 Variables]: 320_shell_variables.html [Shell Scripts]: 700_shell_scripts.html [Control Structures]: 730_control_statements.html [Redirection - Using `elinks`]: 200_redirection.html#example-6-using-elinks-to-fetch-and-search-formatted-web-pages [Nested Control Structures]: 730_control_statements.html#condensing-nested-ifelse-using-elif [The FOR Loop]: 730_control_statements.html#the-for-do-done-loop-statement [Command Substitution]: 710_command_substitution.html [Selecting Fields]: 187_selecting_fields_awk.html [Case Statements]: 730_control_statements.html#the-multi-way-case-esac-statement-with-glob-patterns [Symbolic Links]: 460_symbolic_links.html [Search Path]: 400_search_path.html [relative symlink]: 460_symbolic_links.html#dereferencing-relative-path-symlinks [Reading EMail]: 630_crontab_at_job_scheduler.html#reading-email-from-cron-and-at-jobs [Assignment #09 HTML]: assignment09.html [Academic Honesty Declaration]: academic_honesty.png [AA18]: http://www.algonquincollege.com/policies/policy/academic-discipline/ [AA20]: http://www.algonquincollege.com/policies/policy/plagiarism/ [Source Directory]: #the-source-directory [File Transfer]: 015_file_transfer.html [Assignment #01]: assignment01.html [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/