Updated: 2019-03-27 14:17 EDT

1 Due Date and DeliverablesIndexup to index

Do not print this assignment on paper!

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

2 Purpose and BackgroundIndexup to index

This assignment is based on your weekly Class Notes and covers these topics:

  1. Create shell scripts that deal with parameters and flow control.
  2. Practice with a Linux text editor.

3 How to complete this AssignmentIndexup to index

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.

3.1 Notes on doing assignment workIndexup to index

  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.

3.2 Searching the course notes on the CLSIndexup to index

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.

3.3 The Source DirectoryIndexup to index

All references to the Source Directory below are to the CLS directory ~idallen/cst8207/19w/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.

3.4 Properties of all scriptsIndexup to index

  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.

  1. Make sure that each of your script files is executable, so that it can be executed as ./scriptname.sh from the shell command line.

  2. 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!

  3. 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.

  4. 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.)

  5. 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.

  6. 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.

  7. 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!

  8. Error messages must appear on stderr and follow the format given in Good Error Messages.

  9. Scripts must be documented following the rules in Document Your Script. No documentation means no marks.

  10. If you are having problems with your script and are getting error messages from the shell, review Shell Script Debugging and Script Problems.

4 TasksIndexup to index

Have you completed all the prerequisites, before attempting these tasks?

4.1 Set Up – The Base Directory on the CLSIndexup to index

  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

  1. 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.

4.1.1 Checking only one of your scriptsIndexup to index

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!

4.2 Basic ScriptsIndexup to index

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.

4.2.1 homeWeb.shIndexup to index

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/19w/ from the Internet, formats it, and searches for an optional text string and one line of following (after) context in the formatted page. If no search string is given, search for the default text string: Final Exam: (capitalized, including the punctuation).

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 option that prints one line of trailing context (“after-context”) 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
   2019-04-23 – Week 15 –  Final Exam: 1pm Tuesday April 23 in T119 (1pm to
                           4pm: 3 hours) – 40%


$ ./homeWeb.sh  'Family Day'
   2019-02-18 – Week 6.5 – Monday February 18 – Family Day (College closed)
   2019-02-18 – Week 6.5 – February 18–22 – Study Break Week (no classes


$ ./homeWeb.sh  'Final Assessment'
   2019-04-20 – Week 15 –  Algonquin Final Assessment Week Saturday through
                           Saturday – Exams end after 2019-04-27


$ ./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'
     GNU/Linux operating system, the world's most well-known Free/Libre Open
     Source Software (FLOSS) project and the underlying technology supporting

Notes (Read All The Words):

  1. Review Properties of all Scripts, above.
  2. The successful output is almost always exactly two lines: one line of text found by the text search program and one line of trailing (after) context after that line. See the above examples.
  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.

4.3 Path checking scriptsIndexup to index

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.

4.3.1 thereIs.shIndexup to index

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:

  1. Status of 0 if the pathname exists.
  2. Status of 1 if the pathname does not exist.
  3. 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.

4.3.2 isExec.shIndexup to index

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
  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.

4.3.3 symType.shIndexup to index

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 with awk program 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.

4.4 When you are doneIndexup to index

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

5 Document Your ScriptIndexup to index

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.

5.1 Comments on your scriptIndexup to index

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.

5.2 Academic Honesty Declaration commentsIndexup to index

There is no group work in this course.

Because of the large number of students who have 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 in the text from the Academic Honesty Declaration and add that text to 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. You may use the same text in the bottom of all your scripts.

If your script is found to have text in common with any other people, in this term or any previous term, 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.

Approximately 15% of CST8207 students are charged with plagiarism each term. Don’t be one of them.

6 Checking, Marking, and Submitting your WorkIndexup to index

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!

  1. 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!
  2. 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!
  3. 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!
  4. 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:

READ ALL THE WORDS. OH PLEASE, PLEASE, PLEASE READ ALL THE WORDS!

Author: 
| 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

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