% CST8177 Assignment 07 - Process Management, EMail, crontab, at % Wenjuan Jiang, Ian! D. Allen -- -- [www.idallen.com] % Fall 2014 - September to December 2014 - Updated 2015-09-06 00:38 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**: `23h59 (11:59pm) Friday November 7, 2014 (end of Week 10)` - You have more than one week to do this assignment, but your next assignment will be available in one week and will overlap this assignment. Start work on this now! Don't delay! - Late assignments or wrong file names may not be marked. Please be accurate and punctual. - **Available online** - Version 1 -- 12:00 October 27, 2014 - Version 2 -- 03:30 October 28, 2014 (clarified process_id hints and error checking) - **Prerequisites** - [CST8207 GNU/Linux Operating Systems I] - All Class Notes since the beginning of term. - All your previous [Assignments]. - 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. Directory structure and files created and left for marking on the [Course Linux Server] (**CLS**).\ **Do not delete any assignment work from the CLS until after the term is over!** Purpose of this Assignment ========================== > **Do not print this assignment on paper!** On paper, you cannot follow any > of the hyperlink URLs that lead you to hints and course notes relevant to > answering a question. 1. Create shell scripts that deal with process management, EMail, `crontab`, and `at`. 2. Practise with a text editor. Introduction and Overview ========================= This is an overview of how you are expected to complete this assignment. Read all the words before you start working. For full marks, follow these directions exactly. 1. Complete the **Tasks** listed below. 2. Verify your own work before running the **Checking Program**. 3. Run the **Checking Program** to help you find errors. 4. Submit the output of the **Checking Program** to Blackboard before the due date. 5. **READ ALL THE WORDS** to work effectively and not waste time. Save your work -------------- You will create file system structure in your HOME directory on the CLS, with various directories, files, and links. When you are finished the tasks, leave these files, directories, and links in place as part of your deliverables on the CLS. **Do not delete any assignment work until after the term is over!** Assignments may be re-marked at any time; you must have your term work available right until term end. The Source Directory -------------------- All references to the "Source Directory" below are to the CLS directory `~idallen/cst8177/14f/assignment07/` 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. Searching the course notes -------------------------- The previous term's course notes are available on the Internet here: [CST8207 GNU/Linux Operating Systems I]. All the notes files are also on the CLS. You can learn about how to read and search these files using the command line on the CLS under the heading *Copies of the CST8207 course notes* near the bottom of the page [Course Linux Server]. Review of How To Write and Test Scripts --------------------------------------- Some of the tasks below ask you to write a small executable shell script, based on the lecture notes and slides. All scripts should begin with the Script Header you used for your previous assignments. When you have completed each script, ensure that it is executable, so that it can be run in the current directory as `./scriptname.sh`. Some scripts contain simple one-line pipelines. You can first create these pipelines on the command line, get them working correctly, then copy the working pipeline into the script file when it works. It is much faster to test and fix the pipeline on the command line instead of editing and saving the script file over and over. When you have completed each script, ensure that it is executable, so that it can be run as `./scriptname.sh`. Scripts must validate their arguments, even if they take no arguments. (A script that takes no arguments must not run if you give it arguments, since clearly you don't know how to use it.) Error messages must be written in the style of [Good Error Message], as you did in the previous assignment. Always follow the Good Error Message with a Usage message that says how the script should be run. Scripts that have usage errors should exit with a non-zero exit code, indicating something went wrong. Run the given 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. 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.) Tasks ===== - Do the following tasks in order, from top to bottom. - **READ ALL THE WORDS!** and do not skip steps. - These tasks must be done in your account on the [Course Linux Server]. - Run the [Checking Program] to grade your work, then upload the file to Blackboard. - Your instructor will also mark on the due date the work you do in your account on the CLS. Leave all your work on the CLS and do not modify it. - **Do not delete any assignment work from the CLS until after the course is over.** Set Up -- The Base Directory on the CLS --------------------------------------- 1. Do a [Remote Login] to the [Course Linux Server] (**CLS**) from any existing computer, using the host name appropriate for whether you are on-campus or off-campus. **All work in this assignment must be done on the CLS.** 2. Make an `assignment07` directory in the same directory as you made `assignment02` in a [previous assignment]. > **This `assignment07` directory is the [Base Directory] for most pathnames > in this assignment. Store your files and answers in this Base Directory.** 3. Follow the instructions in the first two steps at the start of [Checking Program] below to create a working symbolic link to the executable **Checking Program**. Check your work so far using the checking program symlink. The Processes Script -------------------- > - Before you write any scripts, re-read the above section with the title > [Review of How To Write and Test Scripts]. > - The material from last term on [Processes] may be useful. Using the specifications below, write an executable script named `process_id.sh` that shows information about processes that are owned by a given *user name* and have a given *command name*. Use the **Hints** below to help you. 1. The `process_id.sh` script must start with the correct Script Header lines. 2. The script takes exactly two arguments. The first is the *user name* of the process owner, and the second is the *command name* of the processes to show: - `./process_id.sh` *user_name* *command_name* 3. The script must print zero or more lines containing process information about every process with the given *command_name* owned by the given *user_name* (if any). 4. The script should show *only* lines for processes owned by the given *user_name* and with the given *process_name*. 5. The script must *not* show any lines for partial user names such as `roo` or `oot` or partial process names such as `bas` or `ash`. Both names given by the user must match fully in the output of `ps`. 6. The script must print a [Good Error Message] and Usage message if it doesn't receive exactly two command line arguments, and exit with an exit status of `2`. 7. The script does *not* have to validate the *user name* or produce any error message if no lines of output are generated. Failing to match any processes is not an error. ### Examples for `process_id.sh` *Your output and numbers will differ.* $ ./process_id.sh "$USER" process_id.sh abcd0001 9170 0.0 0.0 4400 612 pts/2 S+ 10:25 0:00 /bin/sh -u ./process_id.sh abcd0001 process_id.sh $ ./process_id.sh "$USER" bash abcd0001 1647 0.0 0.0 26344 2740 pts/2 Ss Oct22 0:00 -bash $ ./process_id.sh "$USER" sshd abcd0001 1643 0.0 0.0 90508 1308 ? S Oct22 0:02 sshd: abcd0001@pts/2 $ ./process_id.sh root cron root 3574 0.0 0.0 19112 860 ? Ss Oct22 0:03 cron $ ./process_id.sh root sshd | wc -l 10 # should find at least two $ ./process_id.sh oot sshd | wc -l 0 # no such user name $ ./process_id.sh roo sshd | wc -l 0 # no such user name $ ./process_id.sh sshd sshd | wc -l 0 # no such user name $ ./process_id.sh root s | wc -l 0 # no such process name $ ./process_id.sh sshd root | wc -l 0 # no such user or process $ ./process_id.sh one ./process_id.sh: Expecting two arguments, found 1 (one) Usage: ./process_id.sh user_name command_name $ ./process_id.sh one two three ./process_id.sh: Expecting two arguments, found 3 (one two three) Usage: ./process_id.sh user_name command_name ### Hints for `process_id.sh` a. The script will use the `ps` command and a pipeline of one or more commands to select only those `ps` output lines that match the given *user name* and *command name*. b. Refer to your previous assignment work on process listings from [Assignment #02: Creating a script] c. The active part of the script will be one line long (a pipeline). A perfect solution needs only two commands separated by one pipe. d. That one line will be preceded by code to check the number of arguments (two arguments), plus some lines for the Script Header. As with many one-line scripts, the code needed to check the arguments greatly exceeds the code that does useful work! e. Do *not* use any options to `ps` that show **all** processes! You cannot easily search the resulting output for a *command name*. f. Use **only** the two `ps` options described next: 1. The `ps` command has a useful option to display only processes with a particular *command name*. Using this option to select only lines that contain that command name makes the script **much simpler**, since otherwise it is tricky to use `grep` to match a command name in the middle of a line of `ps` output. If you don't use this option to `ps` you must select the command name **carefully** by choosing some surrounding **context** from the output lines using `grep`. I recommend using the `ps` option, not `grep`. 2. In addition to the option that selects *command name*, you will need an option to make `ps` generate a *user name* at the start of every output line. See the man page for either the **full-format** or **user-oriented** output format. Once you make `ps` select lines that have the right *command name*, using `grep` to select lines containing only the correct *user name* is easy since the *user name* field can always be matched as *anchored* at the start of every line. Do not match any *user name* that might occur later in the line. g. You cannot combine the above `ps` option that searches for a *command name* with a `ps` option to also search for a *user name*, since the result will be processes that match a command name *or* that match the *user name*, not processes that match both. Use only the above two `ps` options in your solution. h. Make sure that when you search for a *user name* in the output of `ps` that you use a pattern that ensures that the entire *user name* is matched and not just a prefix or a suffix. The script must *not* show any lines for partial user names such as `roo` or `oot`. i. Do not lines from `ps` that *look* like command names. Often, the script will incorrectly print the `grep` command that is being used to select the right `ps` output line inside the script; don't do that. Show only the required output. j. Test your script and verify that all the **Examples** work. Run the [Checking Program] to verify your work so far. A Signal Trap Test ------------------ Let's use the above script to find a process and then send it some signals. > We are going to be running a shell *background* process for this test. > Normally, the shell won't tell you anything about your background processes > until you push the **Enter** key and get a shell prompt. To get immediate > notification, set the `notify` shell option as described in last term's > [Login and Shell Startup Files]. 1. First, we need to run a test process to receive the signals: Run the script `signaltrap.sh` which is located in the [Source Directory]. You'll notice this script starts and doesn't finish -- it just sits there doing nothing, and you don't get your `bash` prompt back because the script isn't finished yet. The `bash` prompt won't appear until the script process is finished, killed, or stopped. - The script creates a log file in the current directory named `signaltrap_output`. Do not delete this log file. 2. Type `^C` to try to interrupt this script process. - Recall that typing `^C` at a keyboard sends the foreground process an `INT` (interrupt) signal. Most processes die when they receive an interrupt signal. - Notice that the `signaltrap.sh` process did not do the normal thing (die) upon receiving the `INT` signal. It "caught" the signal, printed and logged a message, and refused to die. 3. Type `^Z` at the keyboard to send a `STOP` signal to the `signaltrap.sh` process. - You will get your `bash` prompt back and see a message about the process being `Stopped` by the signal. - The shell built-in `jobs` command will list this as a `Stopped` process. 4. Use `bg` to resume the script process running in the background. - The process will resume, but the shell will not wait for it to finish. You get your shell prompt back and can enter other commands while the background process runs. 5. Use your `process_id.sh` script from above to find the process id of this background script process. - Be sure your script finds *your* process, not any other process! - If your `process_id.sh` script can't find `signaltrap.sh` you may need to adjust it to find commands that are shell scripts. (This may be tricky if you aren't using the `ps` option described in the **Hints** for the `./process_id.sh` script.) 6. At your command prompt, send the `signaltrap.sh` script process a `TERM` signal (terminate) and notice that this too didn't make the process do the expected terminate action (clean up and die). - The script traps and does not die on many signals. You can read the script to see which ones are handled with `trap`. - Read the messages that the script writes into its log file. 7. Finally, send the `signaltrap.sh` process a `KILL` signal. - `KILL` signals can't be ignored, so it should be gone -- verify this. - The shell built-in `jobs` command will show that the process is gone. - Do you know why the script didn't write a log message when it received the `KILL` signal? 8. Find a `PID` of any process owned by `root` or by another user, and try sending it a `KILL` signal (or any other signal). - You will see an `Operation not permitted` error message. - Regular users cannot kill (send signals to) other users' processes. - Re-run the command and *append* the error message to the `signaltrap.sh` log file, below all the other log messages. Do not accidentally erase the messages in the log file! - Verify that the log file contains several log messages and ends with the above error message as the last line. Run the [Checking Program] to verify your work so far. The Temperature Script ---------------------- > - Before you write any scripts, re-read the above section with the title > [Review of How To Write and Test Scripts]. > - The material from last term on [Examples of Pipes] may be useful. Using the specifications below, write an executable script named `temperature.sh` that extracts the current Ottawa Temperature from the appropriate Environment Canada XML **RSS** page. Use the **Hints** below to help you. 1. The `temperature.sh` script must start with the correct Script Header lines. 2. The script will accept no arguments. 3. The script will print one line containing the current Ottawa Temperature, e.g. `Temperature: 6.4°C` 4. The script must print a [Good Error Message] and Usage message if it receives any command line arguments, and exit with an exit status of `2`. 5. Create a hard link to the `temperature.sh` script in your own `bin/` directory and name the link `otemp` 6. Verify that you can now type simply `otemp` at a shell prompt to have the one line of current temperature display. - If this command isn't found, perhaps you haven't set your `PATH` in your `.bashrc` as required in [Section 4.3 of Assignment #02]? ### Examples for `temperature.sh` *Your output will differ.* $ ./temperature.sh Temperature: 6.4°C $ otemp Temperature: 6.4°C $ ./temperature.sh one two three ./temperature.sh: Not expecting any arguments, found 3 (one two three) Usage: ./temperature.sh $ otemp one two /home/abcd0001/bin/otemp: Not expecting any arguments, found 2 (one two) Usage: /home/abcd0001/bin/otemp ### Hints for `temperature.sh` Start by building up the working command pipeline on your interactive command line. Get it working on the command line before you copy the working pipeline into your shell script. a. Refer to last term's work with pipes and web pages shown in CST8207 [Examples of Pipes] and scroll down to the *Display current Ottawa weather temperature* example that fetches the temperature using an `elinks` alias and the Environment Canada XML **RSS** feed. b. As shown in the above example, use the text browser `elinks` with the given options (reproduced below) to retrieve the current Ottawa temperature from the given XML **RSS** feed *URL*: - `elinks -dump -no-numbering -no-references` *URL* - The *URL* should be the Ottawa XML **RSS** feed as shown in the above example. - Make sure you can fetch the entire **RSS** feed web page before continuing with the next steps. If you see "Host not found" or "Page Not Found", you have got the wrong *URL*. c. Pipe the working `elinks` output into `fgrep` to extract the line containing the text string `Temperature:` from the XML **RSS** page. - The pipeline will print one line of current temperature from the XML **RSS** page, e.g. `Temperature: 6.4°C` - You should see only the *one* line of temperature output on your screen when you have the right `fgrep` command line. d. Put the above working two-command pipeline into a script named `temperature.sh` that prints out the current temperature for Ottawa. - The active part of the script will be one line long (a pipeline). - A perfect solution needs only two commands separated by one pipe. e. That one active line will be preceded by code to check the number of arguments (zero arguments), plus some lines for the Script Header. - As with many one-line scripts, the code needed to check the arguments greatly exceeds the code that does useful work! f. Do not create or use an `alias` in your script; use the full `elinks` command line with the correct *URL*. - Scripts never use aliases, since aliases are meant to save typing by humans, not by scripts, and aliases make scripts harder to read. g. If a *URL* contains shell meta-characters, such as `?`, you must [quote the *URL* to prevent GLOB expansion by the shell.]. - Hide all special characters in the *URL* from the shell. h. `elinks` defaults to fetching pages using the UTF8 character set, which may not display well on your screen. - You can change the character set using the `elinks` `-dump-charset` option followed by the name of a new character set. (Try the names `ascii`, `latin1` or the default `utf8`.) i. If the degree special character between the temperature number and the letter `C` doesn't display correctly (e.g. `6.4°C`), you may need to [reconfigure PuTTY for the UTF8 character set]. (Remember to save your PuTTY settings.) j. Test your script and verify that all the **Examples** work. Run the [Checking Program] to verify your work so far. Sending information using a `mail` command ------------------------------------------ System administrators often have systems send them automated EMail. You will build a script that uses EMail to send you the Ottawa temperature. (You can optionally send the temperature to your mobile phone.) > - There are many text-mode EMail clients ("Mail User Agents") for Linux. > This assignment uses the one named `mail`, which is fairly standard and > fairly small, which makes it ideal for use in sending EMail inside > scripts. Learn about [EMail on the CLS]. > - **Optional:** If you are interested in trying a power-user text-mode > mail client for everyday interactive use, try [`mutt`] and read > `man mutt` on the CLS. 1. Learn about [EMail on the CLS], skim over the man page for the `mail` command, and try sending yourself EMail from the CLS to your own EMail account using this pipeline: - `$ echo "Testing mail" | mail -s "Test"` *abcd0001*`@algonquinlive.com` - `$ who | mail -s 'See who list'` *abcd0001*`@algonquinlive.com` - Replace the *abcd0001* with your **own** Algonquin Live EMail address, or use your own personal EMail address instead. - You can pipe any text standard output into the `mail` program; try replacing the command on the left of the pipe with `ls` or `date` or any command that generates *standard output* that you can redirect. - Do not send *binary* data this way; it won't work. **Text Only** - You can use a similar command to send EMail to any of your other EMail accounts. 2. Following the above syntax, EMail the one line of standard output of your above `temperature.sh` weather script to your Algonquin EMail address with the subject: `Current Ottawa Temperature` - If the degree special character between the temperature number and the letter `C` doesn't display correctly in your EMail (e.g. `6.4°C`), read the **Hints** above about option `-dump-charset`. 3. Create a script called `mail_temperature.sh` that will use your `temperature.sh` script and the above EMail syntax to send the current Ottawa temperature to your Algonquin EMail address. (Use the working command line from above.) a. The active part of the script will be one line long (a pipeline). A perfect solution needs only two commands separated by one pipe. Use pipes; do not use any output or input temporary files. b. That one line will be preceded by code to check the number of arguments (no arguments), plus some lines for the Script Header. As with many one-line scripts, the code needed to check the arguments greatly exceeds the code that does useful work! c. The script will use an absolute pathname to your existing `temperature.sh` script to generate the one line of temperature data for the script pipeline. d. Do not duplicate the `elinks` line inside this new mail script; your new script must EMail the *output* created by running your `temperature.sh` script (that contains the `elinks` line). e. You can create this script correctly even if you have not got a working `temperature.sh` script. (Of course, you won't be able to fully test it without a working `temperature.sh` script.) 4. Create a hard link to the `mail_temperature.sh` script in your own `bin/` directory and name the link `omt` (Ottawa Mail Temperature). - Verify that you can now type simply `omt` at a shell prompt to have the temperature sent to you by EMail. (If this command isn't found, re-read the note about `PATH` above in the temperature script section.) Run the [Checking Program] to verify your work so far. > - **Optional:** You can try finding and using an [SMS Gateway List] to > find the EMail address of your SMS enabled phone, and EMail any text > message from the CLS directly to your phone. (May be subject to length > restrictions and incur an arbitrary delay.) > - If the degree special character between the temperature number and the > letter `C` doesn't display correctly in your EMail (e.g. `6.4°C`), read > the **Hints** above about option `-dump-charset`. Scheduling repeated tasks with `crontab` ---------------------------------------- > The `crontab` command is used to create tasks that are run repeatedly by > the system `cron` daemon program. These are commonly called `cron` *jobs*. > You can create personal `cron` jobs. There is also a system file containing > system `cron` jobs that only the super-user can edit. If you don't redirect all the output of command lines used in a `cron` job, any output will be sent to you by EMail. You will need to use the `mail` program to read the EMailed output generated by your `cron` jobs. Learn about [EMail on the CLS]. 1. Read the course notes and the skim the man page for the `crontab` command. 2. Run the CLS command `select-editor` to choose a text editor for use by the `crontab` command. (Isn't it time you learned some `vim`?) 3. Run `crontab -e` to start the selected text editor to edit your personal `crontab` file. - Your personal `crontab` file opens in the text editor with a list of helpful comments, but no actual commands are scheduled. - Use the text editor to add valid `crontab` commands to the bottom of the file, below the comments. The commands you add will not take effect until after you save the file and exit the text editor. - Experiment by creating a `crontab` line that runs in the near future to make sure you know how `cron` jobs work: e.g. create a `crontab` line that runs the `date` command every minute, save, and exit. Wait a minute for the command to execute. - See the note above about where the `date` output will be sent. Learn about [EMail on the CLS]. - Use the `crontab` command again to edit and experiment with other valid `crontab` lines that run in the near future, e.g. two minutes from now, etc. - Use the `crontab` command to remove the test commands from your personal `crontab` when you know enough about how to create working `cron` jobs. 4. Now, create a `crontab` line designed to run your `omt` program (located in your `bin/` directory) at **10:41am** on the first day of every month. - Use a **relative** pathname to run your `omt` program in your `bin/` directory. - **Testing:** Create and save your `crontab` using times in the near future while you are testing your `cron` job to make sure it works. - When you know your job works in the near future, change the time to be exactly the time required for marking. - You can create this `crontab` file correctly even if you have not got a working `omt` script. (Of course you won't receive the correct output without a working `omt` script.) 5. Use the `crontab` command with option that lists the contents of your current live `crontab` file. Make sure your displayed `cron` job is scheduled for **10:41** on the first day of every month. Repeat the above command and redirect the contents of your current live `crontab` file into an `omt.crontab` text file in the [Base Directory]. (It should contain one valid `crontab` line at the bottom of all the comments.) In your `cron` job, did you use a relative path to the `omt` script name (the name that is located in your own `bin/` directory)? You need to know in which directory the `cron` job runs, to create the correct relative path to the program in your `bin/` directory. Run the [Checking Program] to verify your work so far. Scheduling a command once with `at` ----------------------------------- > The `at` command is used to create a task that runs only *once* at some > future date and time. These are commonly called `at` *jobs*. There is no > system file of `at` jobs, since these jobs only run once. If you don't redirect all the output of command lines used in an `at` job, any output will be sent to you by EMail. You will need to use the `mail` program to see the EMailed output generated by your `at` jobs. Learn about [EMail on the CLS]. 1. Read the course notes and skim the man page for the `at` command and note the syntax used to schedule an `at` job at a time and date in the future. Experiment with some `at` command lines that run in the near future to make sure you know how it works. 2. Use the `at` command to schedule a run of your `omt` program (located in your `bin/` directory) at 08:00am, December 25, 2014. - Use an **absolute** pathname to your `omt` program in your `bin/` directory. - **Testing:** Experiment with times in the near future while you are testing the `at` command to make sure it works. - When you know your job works, change the time to be exactly the time required for marking. - You can create this `at` job correctly even if you have not got a working `omt` script. (Of course you won't receive the correct output without a working `omt` script.) 3. Learn the command that displays a list of your scheduled `at` job numbers and display the list to make sure your December 25 job is there. In your `at` job, did you use an absolute path to the `omt` script name (the name is located in your own `bin/` directory)? ### Viewing scheduled `at` jobs You may forget what command is scheduled in a job. What is the command syntax to show you the *content* of a scheduled `at` job, not just the job number? (NOTE: The command that lists all your `at` job numbers is *not* the same as the command that shows you what the content of the job actually is!) In other words, use a command to display the actual command line that you submitted when you created the `at` job, along with all the environment information that the system adds to your `at` job. 1. Using the command above, display the full content of your December 25 `at` job and redirect it into file `atjob.txt` in your base directory. The file should start with a *shebang* line and contain about 30 lines (approximately), most of which are variable assignment statements. > Usually we don't care to see all the environment information at the start > of the queued `at` job file. Assuming that the command being run by `at` is > only one line long (as it is for our December 25 job), you can show *only* > the one-line command line itself on your screen and not see all of the > associated shell environment that is created as part of the job by piping > the output into a command that shows the last lines of input. Run the [Checking Program] to verify your work so far. When you are done ----------------- That is all the tasks you need to do. Check your work a final time using the [Checking Program] and save the output as described below. Submit your mark following the directions below. Checking, Marking, and Submitting your Work =========================================== **Summary:** Do some tasks, then run the checking program to verify your work as you go. You can run the checking program as often as you want. When you have the best mark, upload the marks file to Blackboard. > Since I also do manual marking of student assignments, your final mark may > not be the same as the mark submitted using the current version of the > [Checking Program]. I do not guarantee that any version of the [Checking > Program] will find all the errors in your work. Complete your assignments > according to the specifications, not according to the incomplete set of the > mistakes detected by the [Checking Program]. 1. There is a [Checking Program] named `assignment07check` in the [Source Directory] on the CLS. Create a \[Symbolic Link\] to this program named `check` under your new [Base Directory] on the CLS so that you can easily run the program to check your work and assign your work a mark on the CLS. Note: You can create a symbolic link to this executable program but you do not have permission to read or copy the program file. 2. Execute the above `check` program on the CLS using its symbolic link. (Review the [Search Path] notes if you forget how to run a program by pathname from the command line.) This program will check your work, assign you a mark, and display the output on your screen. (You may want to paginate the long output so you can read all of it.) You may run the `check` program as many times as you wish, to correct mistakes and get the best mark. **Some task sections require you to finish the whole section before running the checking program at the end; you may not always be able to run the checking program successfully after every single task step.** 3. When you are done with checking this assignment, and you like what you see on your screen, **redirect** the output of the [Checking Program] into the text file `assignment07.txt` under your [Base Directory] on the CLS. Use that *exact* name. Case (upper/lower case letters) matters. Be absolutely accurate, as if your marks depended on it. - Do not edit the output file. Submit it exactly as given. - Make sure the file actually contains the output of the checking program! - The file should contain near the bottom a line starting with: `YOUR MARK for` - Really! **MAKE SURE THE FILE HAS YOUR MARKS IN IT!** 4. Transfer the above `assignment07.txt` file from the CLS to your local computer and verify that the file still contains all the output from the checking program. Do not edit this file! No empty files, please! Edited or damaged files will not be marked. You may want to refer to your [File Transfer] notes. - Do not edit the output file. Submit it exactly as given. - Make sure the file actually contains the output of the checking program! - The file should contain near the bottom a line starting with: `YOUR MARK for` - Really! **MAKE SURE THE FILE HAS YOUR MARKS IN IT!** 5. Upload the `assignment07.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 **assignment07** 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 assignment file from your local computer. Make sure the assignment file has the correct name on your local computer before you attach it. 5. After you have attached the file on the *Upload Assignment* page, scroll down to the bottom of the page and use the *Submit* button to actually upload your attached assignment file to Blackboard. Use only *Attach File* on the *Upload Assignment* page. Do not enter any text into the *Text Submission* or *Comments* boxes on Blackboard; I do not read them. Use only the *Attach File* section followed by the *Submit* button. If you need to comment on any assignment submission, send me [EMail]. You can revise and upload the file more than once using the *Start New* button on the *Review Submission History* page to open a new *Upload Assignment* page. I only look at the most recent submission. You must upload the file with the correct name from your local computer; you cannot correct the name as you upload it to Blackboard. 6. **Verify that Blackboard has received your submission**: After using the *Submit* button, you will see a page titled *Review Submission History* that will show all your uploaded submissions for this assignment. Each of your submissions is called an *Attempt* on this page. A drop-down list of all your attempts is available. 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) **Save a screen capture** of the *Review Submission History* page on your local computer, showing the single uploaded file name listed under *SUBMISSION*. If you want to claim that you uploaded the file and Blackboard lost it, you will need this screen capture to prove that you actually uploaded the file. (To date, Blackboard has never lost an uploaded file.) You will also see the *Review Submission History* page any time you already have an assignment attempt uploaded and you click on the underlined **assignment07** 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*. 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 these words. Don't make that mistake! Be exact. **READ ALL THE WORDS. OH PLEASE, PLEASE, PLEASE READ ALL THE WORDS!** -- | Wenjuan Jiang, Todd Kelley, and | Ian! D. Allen - idallen@idallen.ca - Ottawa, Ontario, Canada | Home Page: http://idallen.com/ Contact Improv: http://contactimprov.ca/ | College professor (Free/Libre GNU+Linux) at: http://teaching.idallen.com/ | Defend digital freedom: http://eff.org/ and have fun: http://fools.ca/ [Plain Text] - plain text version of this page in [Pandoc Markdown] format [www.idallen.com]: http://www.idallen.com/ [Course Home Page]: .. [Course Outline]: course_outline.pdf [All Weeks]: indexcgi.cgi [Plain Text]: assignment07.txt [hyperlink URLs]: indexcgi.cgi#XImportant_Notes__alphabetical_order_ [CST8207 GNU/Linux Operating Systems I]: ../../../cst8207/14w [Assignments]: indexcgi.cgi#XAssignments [Checking Program]: #checking-marking-and-submitting-your-work [Course Linux Server]: ../../../cst8207/14f/notes/070_course_linux_server.html [Good Error Message]: assignment06.html#good-error-messages [Remote Login]: ../../../cst8207/14f/notes/110_remote_login.html [previous assignment]: assignment02.html#set-up-the-base-directory-on-the-cls [Base Directory]: #set-up-the-base-directory-on-the-cls [Review of How To Write and Test Scripts]: #review-of-how-to-write-and-test-scripts [Processes]: ../../../cst8207/14w/notes/600_processes_and_jobs.html [Assignment #02: Creating a script]: assignment02.html#creating-a-script [Login and Shell Startup Files]: ../../../cst8207/14f/notes/350_startup_files.html [Source Directory]: #the-source-directory [Examples of Pipes]: ../../../cst8207/14f/notes/200_redirection.html#examples-of-pipes [Section 4.3 of Assignment #02]: assignment02.html#creating-your-first-shell-script [quote the *URL* to prevent GLOB expansion by the shell.]: ../../../cst8207/14f/notes/440_quotes.html [reconfigure PuTTY for the UTF8 character set]: data/putty_utf8.png [EMail on the CLS]: ../../../cst8207/14f/notes/070_course_linux_server.html#email-on-the-cls [`mutt`]: http://www.mutt.org/ [SMS Gateway List]: http://en.wikipedia.org/wiki/List_of_SMS_gateways [Search Path]: ../../../cst8207/14f/notes/400_search_path.html [File Transfer]: ../../../cst8207/14f/notes/015_file_transfer.html [EMail]: mailto:idallen@idallen.ca [Pandoc Markdown]: http://johnmacfarlane.net/pandoc/