% CST8177 Assignment 05 - Shell Script Parameters and Control Flow % Ian! D. Allen – – [www.idallen.com] % Winter 2015 - January to Apil 2015 - Updated Mon Mar 2 15:20:50 EST 2015 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) Tuesday March 3, 2015 (Week 8)` - You have two weeks 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 – 07:00 February 10, 2015 - **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!** **WARNING:** Some inattentive students upload Assignment #05 into the Assignment #04 upload area. Don’t make that mistake! Be exact. 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 parameters and flow control. 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. You can use a [Checking Program] to check your work as you do the tasks. You can check your work with the checking program as often as you like before you submit your final mark. (Some tasks sections below require you to finish the whole section before running the checking program; you may not always be able to run the checking program successfully after every single task step.) > 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**. 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/15w/assignment05/` 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 on the CLS ------------------------------------- The previous term’s course notes are available on the Internet here: [CST8207 GNU/Linux Operating Systems I]. All the notes files are also searchable on the CLS. You can recall how to read and search these files using the command line on the CLS under the heading *Copies of the CST8207 course notes* near the bottom of the page [Course Linux Server Course Notes]. 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 command pipelines (“`|`”) or 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 you used for your previous script assignments. See the class notes. 3. Though the 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 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. When you have completed each script, ensure that it is executable, so that it can be executed as `./scriptname.sh` from the shell command line. 5. 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. 6. Make sure your script handles *all* of the sample inputs given, especially the inputs containing shell metacharacters. (System crackers often attack your system using special characters as input.) 7. The examples below do not fully test your script; you will need to try other examples to make sure your scripts work properly for all possible inputs, especially inputs with blanks and shell meta-characters. 8. Remember to [double quote all variable expansions] to prevent syntax errors and other unwanted problems in your script. Tasks ===== For full marks, follow these task directions below exactly as written. **READ ALL THE WORDS** to work effectively and not waste your time. 1. Complete the **Tasks** listed below, in order, from top to bottom. 2. Do not skip steps. 3. These tasks must be done in your account on the [Course Linux Server]. 4. Verify your own work before running the **Checking Program**. 5. Run the **Checking Program** to help you find errors and grade your work. 6. Submit the grading output of the **Checking Program** to Blackboard before the due date. Your instructor will also mark on the due date the work you do in your account on the CLS. Leave all your work on the CLS and do not modify it. **Do not delete any assignment work from the CLS until after the course is over.** 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. **Base Directory:** Make the CLS **Base Directory** named `~/CST8177-15W/Assignments/assignment05`, in which you will create the files for the following tasks. This CLS `assignment05` directory is the **Base Directory** for most pathnames in this assignment. Store your files and answers in this **Base Directory** on the CLS. 3. Create the `check` symbolic link needed to run the **Checking Program**, as described in the section [Checking Program] below. Use the symbolic link to run the [Checking Program] to verify your work so far. Basic Scripts ------------- These scripts deal with command line arguments and reading input from the user. The concepts here will be used in the next section. Review [Properties of all Scripts], above. ### `arguments.sh` **Arguments on the command line and positional parameters:**\ Create a two-line script named `arguments.sh` that prints to the screen (standard output) exactly two lines: 1. **Line 1:** The number of arguments given to the script, preceded by a short description telling what this output number means. In the examples below, replace `nargsxxx` with your description. 2. **Line 2:** All the arguments themselves, preserving blanks, preceded by a short description telling what this output is. In the examples below, replace `argdescyyy` with your description. Examples: $ ./arguments.sh nargsxxx: 0 # use your own words for nargsxxx argdescyyy: # use your own words for argdescyyy $ ./arguments.sh one two 'three four' '*' nargsxxx: 4 argdescyyy: one two three four * $ ./arguments.sh foo bar >out $ cat out nargsxxx: 2 argdescyyy: foo bar $ ./arguments.sh /bin/* >out $ head -n 1 out nargsxxx: 151 # number may differ $ ./arguments.sh /usr/bin/* >out $ head -n 1 out nargsxxx: 1782 # number may differ Notes: a. Write your own words to replace the descriptive text `nargsxxx` and `argdescyyy` above. Explain in your own words what the output is. b. GLOB characters must *not* expand when output by the script. Add comments to [Document Your Script]. Check your work so far using the checking program symlink. ### `user_input.sh` **Reading input from the user/stdin:**\ Create another two-line script named `user_input.sh` that does two things: 1. **Line 1:** The script prompts on standard error for user input and reads one line of input from the user. In the examples below, replace `promptxxx` with the words of your prompt for user input. 2. **Line 2:** The script displays that one line of input back to the user on standard output, preceded by a short description telling what this output is. In the examples below, replace `descyyy` with your description. Examples: $ ./user_input.sh promptxxx: foo bar # use your own words for promptxxx descyyy: foo bar # use your own words for descyyy $ ./user_input.sh >out promptxxx: * $ cat out descyyy: * $ echo a b c | ./user_input.sh descyyy: a b c Notes: a. Write your own words to replace the descriptive text `promptxxx` and `descyyy` above. Explain in your own words what the output is. b. GLOB characters must *not* expand when output by the script. c. The prompt for user input is on stderr and it does not end in a newline. d. The regular output is on stdout and it is all one line, preceded by a short description telling what this output is. **Hint:** The shell `read` command can be made to prompt for input (see `help read` or look up `read` inside `man bash`), and it correctly displays the prompt on standard error only if standard input is coming from a keyboard. Prompts must never disappear into the output file when standard output is redirected! 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 above Basic Scripts and add error checking and conditional logic. You may find it useful to copy and adapt some of your working code from the above Basic Scripts. Review [Properties of all Scripts], above. ### `path_test_args.sh` **Arguments and conditional statements `if then else`, and `test`:**\ Combine the concepts from the previous scripts and add error checking. Create a script named `path_test_args.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 both a [Good Error Message] and a Usage Message (how to use the script) on stderr and exit with a bad status of `2`. The script must have exactly the following structure and use full `if then else` statements and not conditional operators such as `&&`: # 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 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 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 where `xxx` is whatever argument the user supplied on the command line. The script will exit with a status of: 0. `0` if the pathname exists. 1. `1` if the pathname does not exist. 2. `2` if the number of arguments is not 1, or, if the one argument pathname is the empty string. Examples: $ ./path_test_args.sh >out ./path_test_args.sh: Expecting one pathname argument; found 0 () Usage: ./path_test_args.sh pathname $ echo $? 2 $ ./path_test_args.sh a '*' c >out ./path_test_args.sh: Expecting one pathname argument; found 3 (a * c) Usage: ./path_test_args.sh pathname $ echo $? 2 $ ./path_test_args.sh "" >out ./path_test_args.sh: Argument is an empty string; expecting one pathname. Usage: ./path_test_args.sh pathname $ echo $? 2 $ ./path_test_args.sh path_test_args.sh Pathname exists: path_test_args.sh $ echo $? 0 $ ./path_test_args.sh .. Pathname exists: .. $ echo $? 0 $ ./path_test_args.sh /dev/null Pathname exists: /dev/null $ echo $? 0 $ ./path_test_args.sh /dev/sda Pathname exists: /dev/sda $ echo $? 0 $ ./path_test_args.sh /dev/log Pathname exists: /dev/log $ echo $? 0 $ ./path_test_args.sh nosuchfile Pathname nonexistent: nosuchfile $ echo $? 1 $ ./path_test_args.sh '*' >out $ echo $? 1 $ cat out Pathname nonexistent: * Notes: a. GLOB characters must *not* expand when input by the user or output by the script. b. The regular output is on stdout. c. Each different [Good Error Message] explains clearly what the error is and is followed by a Usage message. Add comments to [Document Your Script]. Check your work so far using the checking program symlink. ### `path_test_user.sh` **Reading input from the user/stdin and testing pathnames:**\ Combine the concepts from the previous scripts and add error checking. Create a script named `path_test_user.sh` that has the same function as the previous `path_test_args.sh` script, but where the input pathname is read from the user instead of coming from an argument on the command line. The script must have exactly the following structure and use full `if then else` statements and not conditional operators such as `&&`: # Follow this exact structure (3 IF statements, 1 ELSE) for your script: if the number of arguments is more than 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 Prompt and read one line of input (a pathname) from the user if the input line is empty (empty string, no input), 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 if the input 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 where `xxx` is whatever pathname the user entered in response to the prompt. The script will exit with a status of: 0. `0` if the pathname exists. 1. `1` if the pathname does not exist. 2. `2` if there are any arguments on the command line, or, if the user entered no input. Notes: a. GLOB characters must *not* expand when input by the user or output by the script. b. The prompt for user input is on stderr and it does not end in a newline. c. The regular output is on stdout. d. Each different [Good Error Message] explains clearly what the error is and is followed by a Usage message. e. Test your script using the same pathnames as you used for your `path_test_args.sh` script, above. Add comments to [Document Your Script]. Check your work so far using the checking program symlink. ### `path_write_loop.sh` **Loop statement `while`:**\ Modify the previous script to create a script named `path_write_loop.sh` that is a looping version of the previous `path_test_user.sh` script. The new script will loop, reading pathname input from the user over and over and testing whether each one is *writable*, until EOF or no input is entered. You might want to copy the previous `path_test_user.sh` script to `path_write_loop.sh` as as starting point and modify it to test for *writable* pathnames instead of *existing* pathnames. The new script must have the following structure and use full `if then else` statements and not conditional operators such as `&&`: # Follow this exact structure (1 WHILE, 3 IF, 1 ELSE): if the number of arguments is more than 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 while prompt and read one line of input (a pathname) from the user if the input line is empty (empty string, no input), then print a message saying there was no input print a friendly good-bye message and exit with status 0 if the input is a pathname that is writable, then print a statement saying that the pathname 'xxx' is writable else print a statement saying that the pathname 'xxx' doesn't exist or is not writable print a message saying EOF was received print a friendly good-bye message and exit with status 0 Examples: $ ./path_write_loop.sh x y z >out ./path_write_loop.sh: Expecting no arguments; found 3 (x y z) Usage: ./path_write_loop.sh $ echo $? 2 $ ./path_write_loop.sh Enter pathname: path_write_loop.sh Pathname is writable: path_write_loop.sh Enter pathname: . Pathname is writable: . Enter pathname: ../.. Pathname is writable: ../.. Enter pathname: nosuchfile Pathname is nonexistent or not writable: nosuchfile Enter pathname: / Pathname is nonexistent or not writable: / Enter pathname: foo bar Pathname is nonexistent or not writable: foo bar Enter pathname: * Pathname is nonexistent or not writable: * Enter pathname: ^D # type CTRL-D for EOF EOF received Goodbye! $ $ ./path_write_loop.sh >out Enter pathname: out Enter pathname: *** Enter pathname: # no input (empty line) $ cat out Pathname is writable: out Pathname is nonexistent or not writable: *** Empty input line. Goodbye! $ $ echo "." | ./path_write_loop.sh Pathname is writable: . EOF received Goodbye! $ $ ./path_write_loop.sh out ./acol.sh: Expecting one column number argument; found 6 (1 2 3 a b c) Usage: ./acol.sh colnum $ echo $? 2 $ echo a b c | ./acol.sh '' ./acol.sh: column number argument is empty Usage: ./acol.sh colnum $ echo $? 2 $ echo a b c | ./acol.sh ' ' ./acol.sh: column number argument is a blank (space) Usage: ./acol.sh colnum $ echo $? 2 $ echo one,two three,four | ./acol.sh 1 one,two $ echo $? 0 $ echo one,two three,four | ./acol.sh NF three,four $ echo $? 0 $ ./acol.sh '*' # test GLOB pattern handling awk: { print $* } # awk errors are allowed here awk: ^ syntax error Add comments to [Document Your Script]. Check your work so far using the checking program symlink. > **OPTIONAL (advanced):** If you want to make the script check for an > argument that is not a number, you can use a shell `case` statement to > match an argument containing any non-digit character and exit with an error > message. Arguments that do not contain non-digits should pass unchanged > through the `case` statement. ### `acol` Link `acol.sh` into your personal `bin/` directory using the name `acol` and use it whenever you need to see just one column of data. Take your `acol` script with you to your next job! $ last | acol 1 | sort | uniq -c | sort -nr | head -5 93 jiangw 90 user1234 87 idallen 82 user2345 77 cst8207a $ last | acol 2 | sort | uniq -c | sort -nr | head -5 450 pts/2 403 pts/3 328 pts/5 235 pts/11 226 pts/8 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] and save the standard output as described below. Submit your mark following the directions below. Document Your Script ==================== Add at least four comment lines (script lines starting with the comment character `#`) to each script containing the following information (in any order): a. The assignment name and number (from the top of the file). b. The question number and script name, e.g. `4.2.1 arguments.sh` c. Your name, your 9-digit student number, and your Algonquin email address. d. A brief summary in your own words of what the script does. The summary can be several comment lines long. 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 the `-p` option to the `read` command. 2. The four or more comment lines should 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 should be **less than 80 characters long**, to fit on your terminal screen nicely. Use multiple comment lines rather than making one huge long comment line. Good Error Messages =================== Good shell script error messages must obey these four rules: 1. Error messages must appear on standard error, not standard output. You can use the shell syntax `1>&2` to send to stderr any output normally destined for stdout. See the examples below. - Usually `1>&2` is used on `echo` statements, to send the text to standard error instead of standard output. 2. Must contain the name of the program that is issuing the message (from `$0`). - Do not put the name of the script into the script; always use `$0`. 3. Must state what kind of input was expected (e.g. `expecting one file name`). - Do not say only “expecting one argument”, since that doesn’t say what *kind* of argument is needed. Be explicit. 4. Must display what the user actually entered (e.g. `found 3 (a b c)` - Display both the number of arguments and their values. *Never* say just `missing argument` or `illegal input` or `invalid input` or `too many`. Always specify what is needed and how many is “too many” or “too few”: echo 1>&2 "$0: Expecting 3 file names; found $# ($*)" echo 1>&2 "$0: Student age '$student_age' is not between $min_age and $max_age" echo 1>&2 "$0: Modify days '$moddays' must be greater than zero" echo 1>&2 "$0: File '$file' does not exist; expecting accounting file" Put quotes around anything entered by a user, otherwise your error messages may be confusing. Compare these example messages without and with quotes around the user input file name: $ ./total.sh still ./total.sh: File still does not exist; expecting accounting file Usage: ./total.sh account_file $ ./total.sh still ./total.sh: File 'still' does not exist; expecting accounting file Usage: ./total.sh account_file After detecting an error, the usual thing to do is print a **Good Error Message** explaining the error, followed by a **Usage** message telling how to use the script, then exit the script with a non-zero return code. Don’t keep processing bad data! 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 `assignment05check` in the [Source Directory] on the CLS. Create a [Symbolic Link] to this program named `check` under your new [Base Directory] on the CLS so that you can easily run the program to check your work and assign your work a mark on the CLS. Note: You can create a symbolic link to this executable program but you do not have permission to read or copy the program file. 2. Execute the above `check` program on the CLS using its symbolic link. (Review the [Search Path] notes if you forget how to run a program by pathname from the command line.) This program will check your work, assign you a mark, and display the output on your screen. (You may want to paginate the long output so you can read all of it.) You may run the `check` program as many times as you wish, to correct mistakes and get the best mark. **Some task sections require you to finish the whole section before running the checking program at the end; you may not always be able to run the checking program successfully after every single task step.** 3. When you are done with checking this assignment, and you like what you see on your screen, **redirect** only the standard output of the [Checking Program] into the text file `assignment05.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 `assignment05.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 `assignment05.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 **assignment05** 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 **assignment05** 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!** ![[Parents: Talk to your kids about Linux]] -- | 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/ [hyperlink URLs]: indexcgi.cgi#XImportant_Notes__alphabetical_order_ [CST8207 GNU/Linux Operating Systems I]: ../../../cst8207/14f [Assignments]: indexcgi.cgi#Assignments [Checking Program]: #checking-marking-and-submitting-your-work [Course Linux Server]: ../../../cst8207/15w/notes/070_course_linux_server.html [Course Linux Server Course Notes]: ../../../cst8207/15w/notes/070_course_linux_server.html#copies-of-the-cst8207-course-notes [Document Your Script]: #document-your-script [double quote all variable expansions]: ../../../cst8207/15w/notes/440_quotes.html#double-quote-all-variable-expansions [Remote Login]: ../../../cst8207/15w/notes/110_remote_login.html [Properties of all Scripts]: #properties-of-all-scripts [Good Error Message]: #good-error-messages [Quoting]: ../../../cst8207/14f/notes/440_quotes.html [Reading eMail]: ../../../cst8207/15w/notes/070_course_linux_server.html#email-on-the-cls [Source Directory]: #the-source-directory [Symbolic Link]: ../../../cst8207/14f/notes/460_symbolic_links.html [Base Directory]: #set-up-the-base-directory-on-the-cls [Search Path]: ../../../cst8207/14f/notes/400_search_path.html [File Transfer]: ../../../cst8207/15w/notes/015_file_transfer.html [EMail]: mailto:idallen@idallen.ca [Parents: Talk to your kids about Linux]: http://xkcd.com/456 [[Parents: Talk to your kids about Linux]]: http://imgs.xkcd.com/comics/cautionary.png "Parents: Talk to your kids about Linux" [Plain Text]: assignment05.txt [Pandoc Markdown]: http://johnmacfarlane.net/pandoc/