CST8207 Assignment 11
tar, syslog, processes, mail, crontab, at, shell script

Ian! D. Allen – www.idallen.com

Winter 2019 - January to April 2019 - Updated 2019-04-02 15:36 EDT

1 Due Date and DeliverablesIndexup to index

Do not print this assignment on paper!

WARNING: Some inattentive students upload Assignment #11 into the Assignment #10 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. Working with tar archives from Tar and Gzip
  2. Working with Processes and Jobs
  3. Working with System Log Files (syslog)
  4. Using the Crontab and At Job Schedulers (cron and at)
  5. Sending EMail and Reading EMail on the CLS.
  6. Writing some very basic Shell Scripts. (No flow control.)

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

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 assignment11 directory in your usual Assignments directory.

    This assignment11 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 assignment for hints on doing the above.

Use the symbolic link to run the Checking Program to verify your work so far.

4.2 Part A – Disk Usage, tar Archive and ListingIndexup to index

You need to know Disk Usage and Tar and Gzip to do this task.

Warning: Shell command completion will often add a slash suffix when you TAB-complete a directory name or a symlink that points to a directory name, e.g. the shell will TAB-complete /etc into /etc/ when you use the TAB key. This is mostly helpful, but will give very different results when you TAB-complete a symlink that points to a directory. If /tmp/foo is a symlink to a directory, then ls -l /tmp/foo shows the symlink itself but ls -l /tmp/foo/ is the same as ls -l /tmp/foo/. and it shows the contents of the entire directory, not just the symlink itself. Be careful when using TAB completion!

  1. Make your Base Directory your current directory and do not change directories for this entire task. All recorded pathnames must be relative to the Base Directory.

    Later in this assignment you will need to copy all the command lines you use in this part into a script file. All command lines must create and use pathnames relative to the current (base) directory.

duMaze11

  1. In the current directory (the Base Directory), create a directory named duMaze11 (and those are two digits at the end of the name).

abcd0001

  1. Without changing directories, create a symbolic link in that duMaze11 directory that is the name of your 8-character CLS userid. The symlink should point to (have a target of) the absolute path of the maze directory that is in the Assignment #03 Source Directory. The symbolic link will have a size of exactly 43 characters (the absolute path of the maze directory), e.g. for userid abcd0001 the left part of the symlink long listing would look similar to this:

    lrwxrwxrwx 1 abcd0001 abcd0001 43 Mar 11 10:00 duMaze11/abcd0001 -> 

    The rest of the symlink (not shown) is the absolute path of the Assignment #03 maze directory.

    You probably have the symlink correct if ls duMaze11/abcd0001 (use your own accout name) shows over 1,300 (non-hidden) pathnames from the maze.

mzBlocks.txt

  1. Without changing directories, use redirection to save a long listing of the one symlink (only the one symlink, not the whole directory) into a new file mzBlocks.txt in the duMaze11 directory. The new file will contain one line, 11 words, 112 characters. Do not use any options other than the one that produces a long listing of the symlink.

  2. Display the sum total of disk blocks in the hidden duMaze11/abcd0001/.1/.8 sub-directory inside the maze. Do not change directories to do this!

    • Use your own symlink and userid in the name, not abcd0001
    • The number of blocks printed should be larger than 500.
    • The relative pathname beside the number should include your symlink pathname exactly as given above.
    • You will need this exact relative pathname in the next questions.
    • If you get the wrong pathname, re-read the first sentence of Item #1, above about not changing directories.

mzBlocks.txt

  1. Append the above one-line of output (the number of disk blocks) to the existing mzBlocks.txt file.
    • The file will now be two lines long. The second line will contain two words: a number larger than 500 and a relative pathname containing three slashes.
    • If you get the wrong pathname, re-read the first sentence of Item #1, above about not changing directories.

YYYYMMDD.tar.gz

  1. Use a single command to create a gzip-style compressed tar archive in the duMaze11 directory containing the contents of the .1/.8 directory from above. Use the relative pathname from above as the source of the files to archive. Name the new archive YYYYMMDD.tar.gz (no spaces) under duMaze11, where YYYYMMDD is the numeric year-month-day date of the Final Exam in this course (a Tuesday in April for 19w).
    • Do not let the tar command display the file names as they are added to the archive; add the files silently, not verbosely.
    • The gzip-style compressed archive will be approximately 1,600 bytes.
    • Generate a table of contents of this archive and show only the first 10 lines on your screen. (Don’t show all the lines!)
    • All the pathnames in the tar archive file must be relative paths with duMaze11/abcd0001/.1/.8 at the beginning of every name (using your userid).
    • The archive should contain about 128 pathnames. (Generate a table of contents and confirm this.)
    • If you get the wrong pathnames, re-read the first sentence of Item #1, above about not changing directories.

YYYYMMDD.tar.bz2

  1. Create a bzip2-style compressed tar archive in the duMaze11 directory of the same .1/.8 directory from above. Use the same date name as for the gzip archive, but use the file extension .bz2 instead of the .gz extension.
    • Use the correct options to generate the bzip2-style compressed archive, and also use the correct output name.
    • The bzip2-style compressed archive will be approximately 1690 bytes. If it’s much larger than that, you didn’t use the right options to create it.
    • Generate a table of contents of this archive and show only the first 10 lines on your screen. (Don’t show all the lines!)
    • All the pathnames in the tar archive file must be relative paths with duMaze11/abcd0001/.1/.8 at the beginning of every name (using your userid).
    • The archive should contain about 128 pathnames. (Generate a table of contents and confirm this.)
    • If you get the wrong pathnames, re-read the first sentence of Item #1, above about not changing directories.
  2. Look up the option to ls that gives just “the allocated size of each file, in blocks” and use that option (and only that option) to display the size and name of the two tar archives you just created in the duMaze11 directory.
    • A GLOB pattern will be helpful to generate the two archive pathnames in the duMaze11 directory as arguments to ls.
    • The output will be one line long, four words, with each tar archive name (relative pathnames) preceded by its size in blocks.

mzBlocks.txt

  1. Append the output of the above command line (the sizes and relative pathnames) to the existing disk blocks file you created earlier. The file will now be four lines long. The last three lines will contain exactly two blank-separated words each.
    • Note how the output of ls changes to be on separate lines when output is to a file instead of directly to your screen. This is one of the few commands that does this.
    • Look at the last three lines in the disk blocks file and note how the compressed tar archives are much smaller (fewer disk blocks) than the original disk space used.
    • Note how the newer bzip2 compression algorithm is better at compressing this file (smaller file size) than the older gzip algorithm. (In this small example, both files may use the same minimum number of disk blocks.)
    Hint: Go back and re-read the first step #1 in this task if you don’t have the right relative pathnames in your output.

tarTable.txt

  1. Generate a verbose listing of the table of contents of your gzip-style tar archive file, showing the contents of the archive including all the owners and date/time stamps, but don’t display it directly on your screen since it’s over 128 lines long. (Generate the verbose listing and verify that it outputs over 128 lines by counting them with a pipe.)

    Once you know you can generate the verbose listing, save just the first five and last five lines of the verbose listing into file tarTable.txt under your duMaze11 directory. The file word count will be 10 63 817 and the first line and last line should look similar to this (where abcd0001 is replaced by your userid):

    drwxr-xr-x idallen/idallen   0 2001-01-01 00:00 duMaze11/abcd0001/.1/.8/
    drwxr-xr-x idallen/idallen   0 2001-01-01 00:00 duMaze11/cst8207b/.1/.8/.1/.1/

    Hints: You will need to use one command pipeline to generate the first five lines into the output file, and then use a second command pipeline to generate the last five lines and append them to the output file to make a total of ten lines in the file. If the checking program says you have unprintable characters in your file, you have not used the right command to generate a verbose listing of a tar file; re-read the notes on how to use tar given at the top of this Part A section.

  2. The bzip2 compression algorithm is better than the gzip compression algorithm; bzip2 produces smaller compressed files. Answer this question:

    True or False: Because bzip2 output is smaller than gzip output, generating the verbose table of contents of the bzip2-style tar archive file will produce fewer lines than the table of contents of the gzip-style archive.

    Append your one-word answer true or false to the tarTable.txt file. (The file will now contain 11 lines.) (The checking program will not check this answer. Your instructor will check the answer and mark it after you hand in your assignment.)

Run the Checking Program on the CLS to verify your work so far.

If you have errors, go back and re-read the first step #1 in this task.

4.3 Part B – The Mystery Puzzle FileIndexup to index

You need to know Tar and Gzip to do this task.

After you have run the Checking Program at least once, you will find created for you in the Source Directory a puzzle file in a puzzle subdirectory named with your userid puzzle/abcd0001.mystery where abcd0001 is replaced by your own userid. This file contains many layers of compression and tar and zip archiving.

puzzle.txt

  1. Extract the ASCII text file from deep inside this puzzle file and save the ASCII text as file puzzle.txt in your Base Directory.

    Hints: Copy the file to your account and then repeatedly unpack the compression and tar and zip archiving until you find an ASCII text file. The file has many layers (ten or more)! The file command will be helpful to identify each nested layer of the puzzle. You will need to fix the permissions and possibly the file extensions on some of the nested files as you try to uncompress and extract them.

    I will demonstrate one way of decoding this puzzle in class – see your class notes.

Run the Checking Program on the CLS to verify your work so far.

4.3.1 The Soul Needle of Koschei the Deathless

This section is from Slavic folklore and is not part of this Assignment. Folklore courtesy of your classmate Roman Kshnikatkin:

In Slavic folklore, Koschei (Russian: Коще́й, tr. Koshchey, IPA: [kɐˈɕːej]), often given the epithet “the Immortal”, or “the Deathless” (Russian: Коще́й Бессме́ртный), is an archetypal male antagonist. The most common feature of tales involving Koshchei is his spell protection against being killed – he has hidden his soul inside nested objects, usually in a needle.

The soul of this Warlock is on the tip of a needle, the needle is in an egg, the egg is in a duck, the duck is in a rabbit, the rabbit is in a chest, the chest is hanging down from the tallest oak secured with chains, the oak is on the far Island named Buyan somewhere in the ocean. So to kill him, go to the Island, find an oak, break the chains, get the chest, catch the rabbit, then get the duck out of the rabbit, then get the egg out of the duck, break the egg, get the needle, and break the needle!

Wikipedia English – Koschei Wikipedia Russian – Кощей — Википедия

4.4 Part C – Process ListingIndexup to index

You need to know Processes and Jobs to do this task.

psBSD.txt

  1. Place a list of your own processes in BSD format, text user name (not numeric UID) into file psBSD.txt in your Base Directory. Only a few lines will display and your userid will be at the start of every line. The first header line of the output must look like this (this is BSD format):

    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

psBSD.txt

  1. Append a full list of all processes for all users, BSD format, text user name (not numeric UID), full wide listing (not truncated at all) to the same file psBSD.txt.

    Hints: The file should now be more than 100 lines and 10KB. One of the very long lines will be a dhclient line similar to this (use a text-searching command to find it in the output):

    root      1037  0.0  0.0  16132  1328 ?        Ss   Mar07   0:00 /sbin/dhclient -1 -v -pf /run/dhclient.enp0s3.pid -lf /var/lib/dhcp/dhclient.enp0s3.leases -I -df /var/lib/dhcp/dhclient6.enp0s3.leases enp0s3 -e IF_METRIC=9999

    If you don’t see the full line width, including the 9999 number at the end, re-read the question and use all the options.

psmine.txt

  1. Select just the first line (the header line) of the psBSD.txt file and put a copy of that one line into the file psmine.txt
    • There is a command that can do this easily.
    • The file will be 1 line, 11 words, 73 characters.
    • Save the one BSD header line in the file, not the word count!
    • Do not change the psBSD.txt file.
  2. Find all lines in psBSD.txt that contain your userid anywhere in the line and append those lines to the psmine.txt file. (Some of the lines in this file may be very long.)

Run the Checking Program on the CLS to verify your work so far.

4.5 Part D – System Log FilesIndexup to index

You need to know System Log Files to do this task.

syslog.txt

  1. What is the actual name of the syslog daemon program that is running on the CLS? Search for and extract the one line from psBSD.txt that contains this name and redirect the results (one line) into file syslog.txt (one line, 12 words).

authlogi.txt

  1. The system authentication log file is named auth.log in the system log directory. Generate an ls long listing showing inode number of this file using the full absolute pathname and put the output into file authlogi.txt. (The file should be one line, 10 words, starting with an inode number, showing the permissions, owner, group, date, etc.)

al

  1. Create an absolute symbolic link in your Base Directory to the above system log file. Name the symlink al – a nice short name. You might find using this short symlink useful in subsequent items in this assignment that require you to look in this log file.

authlogi.txt

  1. Append a long listing of the above symlink to the authlogi.txt file. (The file will now contain two lines, 21 words.)

meIDs.txt

  1. Use one command name (no arguments) to put a list (one line) of your numeric UID, your userid, your numeric GID, your group name, and your additional group names into the file meIDs.txt. The result will be 1 (long) line, 3 words. See Permissions for the command to use to do this. Do not edit the output of the command.

meperms.txt

  1. Use a text editor (or other means) to enter just the numeric UID for your account into file meperms.txt (one number). (The UID number was displayed by the command you used in the previous step.)

meperms.txt

  1. Look at the contents of the meIDs.txt and authlogi.txt files. Note that your account is in a group that matches the group of the system auth.log file, giving you group permissions on this file. Using a text editor, append the matching group name (one word), the symbolic group permissions (three characters), and the octal group permissions (one digit), onto three more lines in file meperms.txt. (The appended result will make the file 4 lines and 4 words, with one word on each line in the file.)

authhead.txt

  1. The system auth.log file for this term contains over 430,000 lines (as of mid-March 2019). (Make sure this is true before you continue.) Use a command to extract just the first line (one line) from the beginning of this file and redirect that one line into new file authhead.txt. (The result will be 1 line 13 words 112 chars.) The time and date at the start of this line is when this copy of the log file was started.

authhead.txt

  1. Append the same information that you put in the last line of the authlogi.txt file above (about the al symlink) to the authhead.txt file, making the file two lines long (24 words).

failedpass.txt

  1. If you count the number of lines in the system auth.log containing the exact text string Failed password, the count is more than 21,000 lines as of March 2019. (Make sure this is true before you continue.) Of those lines (the lines containing that exact text string), use a command pipeline to extract just lines 110 through 121 (inclusive) and put only those lines into file failedpass.txt. Every line should contain the above exact text string somewhere.

    Hint: You solved a similar problem in Worksheet #05 PDF and on your midterm and practice tests. The correct output should contain 192 words and 1416 characters. All the selected log lines have a date on January 2 after 12:28.

Run the Checking Program on the CLS to verify your work so far.

4.6 Part E – CrontabIndexup to index

This section assumes that you have no personal crontab created. If you have created one, remove it before you begin and work all the way to the end of this Part before you check your work.

You need to know Crontab and At Job Schedulers and Differences between text files to do this task.

Re-read the Notes on doing assignment work before you continue. You cannot check your work in the middle of this task part.

minutepid.txt

  1. Create a personal crontab entry, often called a cron job, that echoes the value of the shell process ID variable into file minutepid.txt in your Base Directory every minute of every day. The command in your crontab should redirect the command output into the shortest relative pathname to the minutepid.txt file.

    After you create your crontab, verify that the pid number in the file changes every minute. (You may have to wait up to a minute before the cron runs your job for the first time.)

    Hints: If it doesn’t work, read your Linux EMail for EMail messages from the Cron daemon suggesting possible errors. See Reading EMail for help. The single working crontab line should have five fields for the date/time, an echo command with a single shell variable argument, and redirection into a relative pathname into your Base Directory, not into your HOME directory. Do not use an absolute pathname.

Do NOT check your work yet.

crontab_list1.txt

  1. Use a command to list your personal crontab that you just created (one entry, with perhaps some comment lines) and redirect the output into file crontab_list1.txt in your Base Directory. This crontab entry is the one that runs every minute.

  2. Delete your personal crontab (the one that runs every minute).

differ.txt

  1. Use a command and two absolute pathnames that shows the Differences between text files between the Linux password file and its backup copy. (The backup copy has the same name with a dash “-” appended.) A few lines should display, or perhaps none if the files are identical.

  2. When you have the password file line difference command correct, create a personal crontab entry that runs that same command and redirects the output into the file differ.txt in your Base Directory at your Personal Crontab Time. Also use a relative pathname to the output file, not an absolute pathname.

crontab_list2.txt

  1. List your personal crontab (just one entry running at your Personal Crontab Time, with perhaps some comment lines) and redirect the output into file crontab_list2.txt. Do not delete this personal crontab entry; leave it for marking. Make sure your displayed cron job is scheduled to run at your Personal Crontab Time.

Run the Checking Program on the CLS to verify your work so far.

Re-read the Notes on doing assignment work if you are trying to check your work in the middle of a task instead of at the end of a task.

4.7 Part F – At Job ReminderIndexup to index

Re-read the Notes on doing assignment work if you are trying to check your work in the middle of a task instead of at the end of a task.

You need to know Crontab and At Job Schedulers to do this task.

  1. Job 1: Create an at job that prints the list of logged-in users on the system, one per line, at your Personal Crontab Time in the year 2021. You can use any of several commands from this course to show the list of logged-in users one per line; see the List of Commands You Should Know.

    Hints: You need to get the order of the date correct on the at command line; see the Crontab and At Job Schedulers course notes or RTFM to find out how to specify both a time and a date for an at job. No pipes or redirection or files are needed for this command in the at job; it’s just running one single command name.

  2. Display your list of at jobs to confirm the correct scheduling date and time in 2021.

  3. Job 2: Create an at job that runs the command that prints the log messages in the kernel ring buffer. Schedule the job at your Personal Crontab Time in the year 2021. (See the List of Commands You Should Know.)

    Hints: No pipes are needed for this at job; it’s just one command name that displays the in-memory kernel log buffer. Look in your weekly command list for the command name you need.

  4. Job 3: Create an at job that echoes this single argument (9 words) “CST8207 Final Exam 1pm * Tomorrow * in T119” as a mail message to your Algonquin Live EMail account at 2 PM on the day before your final exam in this course. (Your final exam is at 1pm on a Tuesday in April for 19w. Go find the exact date and put a reminder in your phone.) The EMail message body sent using echo at 2pm on the day prior must have the exact message text above as one argument and the exact Subject line of the EMail must also be one argument (eight words): CST8207 Final Exam 1pm * TOMORROW * Tuesday

    Hints: A pipe will be needed to connect the one-line output of echo with the standard input of the mail program. See Sending EMail for help in sending EMail with a subject line. Did you use the exact (and different) words given to you for the message body and Subject texts? Did you make sure each set of words is one argument to the shell?

    Hints: Test that your mail pipeline works (sends you email) at your CLS command line before you copy the pipeline into the at job for later execution! Make sure that your pipeline actually works at the command line before you put it into the at job.

  5. Check the queue of at jobs and make sure the scheduled times are correct for all three jobs.

  6. Delete just the (first) at job that shows the list of users.

atjob.txt

  1. Display both your remaining queued at jobs and redirect the output into file atjob.txt. You will only have two jobs – two lines. If you have more than two lines, delete the other jobs.

  2. Leave these two jobs queued on the CLS for marking.

Run the Checking Program on the CLS to verify your work so far.

Re-read the Notes on doing assignment work if you are trying to check your work in the middle of a task instead of at the end of a task.

4.8 Part G – Shell ScriptsIndexup to index

You need to know basic Shell Scripts to do this task.

4.8.1 Properties of all scripts

  1. None of the scripts in this assignment need control flow statements. They are all simple linear scripts.

  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. Scripts must be documented following the rules in Document Your Script.

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

4.8.2 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 partA.sh                        # only check this script
$ ./check partA.sh showargs.sh            # only check these two scripts

Do not submit for marking the output of checking only a few scripts!

4.8.3 Shell script: partA.sh

Topic: Simple linear shell script; no parameters or control statements

You need to understand basic Shell Scripts to do this. No flow control statements are needed.

  1. Write an executable Bourne shell script named partA.sh that does automatically all the manual work you did creating files in Part A of this assignment. The script must create and use the new output directory name duMaze99 (in the current directory) instead of the original directory name duMaze11. The script should show no output on your screen; it should create all its files with no output on your screen.

Hints and Notes:

  1. Do not change directories inside the script.
  2. The first three executable lines of the script file should be the three lines of the Standard Script Header. You can insert # comment lines after the first line, but not before it.
  3. Make the script file editable and executable for only the owner (you). Group can read the file but not write or execute it. No other permissions. Hint: Review Permissions.
  4. The script should recursively and silently remove any existing duMaze99 from the current directory at the start of the script. (You used a command to do this silent recursive removal in almost every new Lab section of every Worksheet.)
  5. Create a new directory named duMaze99 in the current directory.
  6. Run sufficient commands to create the symlink and four files from Part A, inside the new duMaze99 directory.
  7. Do not change directories inside your script file.
  8. Use the new duMaze99 directory for all output.
  9. The working script must not show any output on your screen.

Having already done Part A, your bash shell history already contains all the command lines you need for your script. All you need to do is adapt each command line to use the duMaze99 directory instead of the original directory. My solution script contained three lines of Standard Script Header followed by about ten command lines to create the directory, the symlink, and the four files from Part A. Make sure you test run your script before you run the Checking Program!

Add comments and a KEY line to Document Your Script.

Run the Checking Program on the CLS to verify your work so far.

4.8.4 Shell script: showargs.sh

Topic: Arguments on the command line and positional parameters:

You need to understand basic Shell Scripts with argument parameters to do this. No flow control statements are needed.

Create a three-line script named showargs.sh that prints to the screen (standard output) exactly three lines:

  1. Line 1: The name of the script, using the correct shell variable.
  2. Line 2: 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. The number must appear on the same line as the description.
  3. Line 3: 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. The arguments must appear on the same line as the description.

Make sure all the examples below work before you run the Checking Program! Examples:

$ ./showargs.sh
./showargs.sh                            # from the correct shell variable
nargsxxx: 0                              # use your own words for nargsxxx
argdescyyy:                              # use your own words for argdescyyy

$ ./showargs.sh one   two    'three      four'   '*'
./showargs.sh                            # from the correct shell variable
nargsxxx: 4
argdescyyy: one two three      four *

$ ./showargs.sh foo bar >out
$ cat out
./showargs.sh                            # from the correct shell variable
nargsxxx: 2
argdescyyy: foo bar

$ ./showargs.sh /bin/* >out
$ head -n 2 out
./showargs.sh                            # from the correct shell variable
nargsxxx: 151                            # number may differ

$ ./showargs.sh /usr/bin/* >out
$ head -n 2 out
./showargs.sh                            # from the correct shell variable
nargsxxx: 1782                           # number may differ

Hints and Notes:

  1. Review Properties of all Scripts, above.
  2. Write your own words to replace the descriptive text nargsxxx and argdescyyy above. Explain in your own words what the output is.
  3. GLOB characters must not expand when output by the script.
  4. The standard output is always exactly three lines, no more, no less. You should check this yourself to make sure.

Add comments and a KEY line to Document Your Script.

Run the Checking Program on the CLS to verify your work so far.

4.9 Part H – Personal bin directoryIndexup to index

You need to know Shell Scripts, Search Path, Start-Up Files, and Symbolic Links to do this task.

bin

  1. Create your own personal bin directory in which to keep your own personal Linux commands. Use the exact name bin and create it in your HOME directory.

  2. Append your bin directory path to the end (right end) of your search PATH. Do this at login time in your shell start-up file so that it applies to all shells.

    Hints: Review Search Path, Start-Up Files, and Working with your search PATH in Assignment #07 HTML. Remember that you must have your shell re-read your start-up file for the new search path to take effect.

partA

  1. Create a relative symlink named partA in your bin directory. The symlink should point to (have a target of) your partA.sh script file that you just created.

    Hints: Review Symbolic Links. The relative symlink target from your bin directory to your script will contain four slashes.

  2. Make sure that you can now type your new command name partA at your shell to execute your partA.sh shell script. If the command is not found, re-read all the Hints, above.

showargs

  1. Repeat the above for the showargs.sh script, naming the symlink showargs in your bin directory.

  2. Make sure that you can now type your new command name showargs at your shell to execute your showargs.sh shell script. If the command is not found, re-read all the Hints, above.

Run the Checking Program on the CLS to verify your work so far.

4.10 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 EMail on the CLS 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

Nothing seriously bad will happen if you forget to log out, but you may leave behind an empty, “ghost” login session that may take some days to time out and disappear. Always exit before you close your laptop, PuTTY, or Terminal session.

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.

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 (copied exactly from the top of the assignment page, i.e. Assignment 11).
  2. The question number and script name, e.g. 4.8.4 showargs.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 showargs.sh The Signing Key comment line must start with # KEY: and will be about 80-89 characters long.
  5. A brief summary in your own words of what the script does. The summary can be one or more comment lines long. The comments will be read and marked by your professor after you have submitted your lab; the Checking Program cannot evaluate the quality of what you write. Poor comments means poor marks.

Obey these rules for your script comments:

  1. Use your own words to describe your script; don’t copy mine. Your description might document any special features that are worth noting and remembering.
  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
# 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.

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

  3. When you are done with this assignment, and you like the mark displayed on your screen by the Checking Program, you must redirect only the standard output of the Checking Program into the text file assignment11.txt in your Base Directory on the CLS, like this:

    $ ./check >assignment11.txt
    • Use standard output redirection with that exact assignment11.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 assignment11.txt
    • In less use the space bar to page forward and use the letter q to quit).
    • Make sure the file actually contains the output of the Checking Program!
    • The file should contain, near the bottom, a line starting with: YOUR MARK for
    • Really! MAKE SURE THE FILE HAS YOUR MARKS IN IT!
  4. Transfer the above single file assignment11.txt (containing the output from the Checking Program) from the CLS Base Directory to your local computer.

    • Refer to the File Transfer page for how to transfer the file.
    • Verify that the file still contains all the output from the Checking Program.
    • Do not edit or open and save this file on your local computer! Edited or damaged files will not be marked. Submit the file exactly as given.
    • The file should contain, near the bottom, a line starting with: YOUR MARK for
    • Really! MAKE SURE THE FILE YOU UPLOAD HAS YOUR MARKS IN IT!
  5. Upload the single assignment11.txt file from your local computer to the correct A-11 Assignment #11 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 assignment11.txt name. Do not use any of the names from Assignment 1.
    • Make sure you upload it to the right place, not into Assignment 10 or 9!
  6. Your instructor may also mark files in your directory in your CLS account after the due date. Leave everything there on the CLS. Do not delete any assignment work from the CLS until after the term is over!

Notes:

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

7 Appendix I: Your Personal Crontab TimeIndexup to index

This section shows you how to calculate your Personal Crontab Time for use in your cron and at jobs. You need to know your nine-digit student number and how to calculate the arithmetic modulus of a number.

  1. Take your 9-digit student number and remove the first three digits (probably 040), leaving six digits. Use these last six digits as follows:
  2. Take the first two of those six digits as a number, modulo 12, and then add 1, giving a number between 1 and 12. This is your month number.
  3. Take the next (middle) two of those six digits as a number, modulo 24, giving a number between 0 and 23. This is your hour number.
  4. Take the last two of those six digits as a number, modulo 60, giving a number between 0 and 59. This is your minute number.
  5. Take the same last two of those six digits as a number, modulo 28, and then add 1, giving a number between 1 and 28. This is your day-of-the-month number.

For example, if your nine-digit student number were 123456789:

  1. Remove the first three digits 123, leaving the last six digits 45 67 89
  2. Using the first two digits 45, the month would be (45 mod 12) + 1 = 10 (October)
  3. Using the next two digits 67, the hour would be 67 mod 24 = 19 (7pm)
  4. Using the last two digits 89, the minute would be 89 mod 60 = 29
  5. Using the last two digits 89, the day of the month would be (89 mod 28) + 1 = 6

The Personal Crontab Time for student number 123456789 is October 6 at 19h29 (7:29pm).

Exercise: Show that the Personal Crontab Time for student number 987654321 is June 22 at 19h21 (7:21pm):

  1. last six digits = 65 43 21
  2. month = 6 (June)
  3. hour = 19 (7pm)
  4. minute = 21
  5. day of month = 22

which is June 22 at 19h21 (7:21pm).

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