------------------------
Week 8 Notes for DAT2330
------------------------
-Ian! D. Allen - idallen@idallen.ca

Remember - knowing how to find out an answer is more important than
memorizing the answer.  Learn to fish!  RTFM!  (Read The Fine Manual)

------
Review
------

In Week 7 (week07notes.txt) you learned about gzip/gunzip and
bzip2/bunzip2.  You understand how your umask affects the permissions of
new files and directories.  You know how to set PATH and umask at the
start of a shell script.  You can write basic shell IF/ELIF/ELSE/FI,
WHILE/DO/DONE, and FOR/IN/DO/DONE control structures.  You can compile
and run a basic C and C++ program.

You now know some basic meaning and usage of these Unix/Linux commands:

   bash passwd pwd cd mkdir rmdir rm ls
   vim cat more less man echo cp stty
   du wc date chmod who
   mesg mv head tail touch sort grep file diff
   sleep which whereis
   ^Z fg bg kill
   ln tar
   ssh scp ftp
   umask  if/else/elsif/fi  while/do/done   for/in/do/done
   gzip   gunzip   bzip2   bunzip2  zcat  zless   zgrep

------------------
This Week (Week 8)
------------------

In-Lab Exercise:

    You did an in-lab Exercise #7 and submitted it in the lab.
    (See the Notes readings, below, for the sample solution.)

Unix commands used this week (RTFM):

    if/else/elif/fi  while/do/done

1.  Readings in Running Linux:
    
    * "Shell Programming" Chapter 13, p.448

2.  Read these files under the Notes button on the course home page:

    script_practice1.txt       - Practice Script #1 Specifications
    labweek8.sh.txt            - Sample solution for script_practice1.txt
    exit_status.txt            - Return Code, Exit Status, test, if, and while
    shell_script_execution.txt - How a Shell Script is "Executed"
    quick_tests.txt   - Return Code, Exit Status, ||, &&, test, and if
    less_code.txt     - Less Code is Better Code - stop cutting and pasting
    script_style.txt  - Shell Script Programming Conventions and Style
    deep_nesting.txt  - Avoiding deeply nested IF statements
    redirection.txt   - Unix Shell I/O Redirection (including Input)
    script_checklist.txt  - Shell Script Checklist - things to verify
    *.sh.txt              - many sample shell scripts

3.  Start work on DAT2330 Exercise #8 (when available).
    Submit it by the due date.

Notes:

  - The DAT2330 script header is documented in script_style.txt .
  - The four parts of a Good Error Message are in script_style.txt .
    Make sure error messages appear on standard error, not standard output.

Shell variables:

  $# - count of command line arguments (never negative)
  $0 - name of the currently executing shell script
  $? - exit status of the previous command
  $* - a list of all arguments on the command line
  $1,$2,$3,... - first, second, third argument, ...

  DOUBLE QUOTE ALL VARIABLES to protect contents from unwanted shell GLOBbing.
  Double quotes permit the shell to expand the variables; but, they
  stop GLOB metacharacters from being expanded.

  Quoted strings are always one single argument, except for "$@" special case.

  Use variables to hold constants (like you use #define in C)
  - reduce maintenance: how many edits needed to change a constant?

Command substitution:

  - similar to variable substitution; but, it is the output of the
    given Unix command that is substituted

  - syntax:  $( any Unix command goes between parentheses )

  - *all* the standard output of the command(s) betwen parentheses is captured

  - typical use is to assign command output to a shell variable:

    $ users=$( who | wc -l )
    $ echo "Number of users logged in: $users"

    $ words=$( wc -w </etc/passwd )
    $ echo "The passwd file contains $words words"

  - you can only capture what you can see; if the command produces no
    standard output, nothing will be captured by command substitution

    $ foo=$( cp /etc/passwd bar )
    $ echo "$foo"
    $
    - empty, because "cp" has no standard output to capture

Input redirection from files:

  - a pipe allows a command to get standard input from some other
    program, e.g.

    $ who | tr a-z A-Z

  - the shell also has an input redirection syntax that allows a command
    to get standard input from a file instead of a program:

    $ tr a-z A-Z <file

  - the program must read standard input for this to work; if the
    program ignores standard input, the redirection is ignored (this
    applies to input from pipes as well - piped input is ignored if
    the command does not read standard input):

    $ wc -l /etc/passwd <foo    # input redirection from foo is ignored
    $ wc -l             <foo    # input redirection from foo works

  - input redirection allows us to use the output of "wc" without the
    file name:

    $ wc -l  /etc/passwd
     55 /etc/passwd                 # file name argument appears in output
    $ wc -l </etc/passwd
     55                             # stdin is used; NO file name appears

    $ x=$( wc -l /etc/passwd )
    $ if [ $x -gt 0 ] ; then echo hi ; fi
    sh: [: too many arguments       # error due to $x containing file name

    - the shell expands $x into two arguments:  55 /etc/passwd
      the resulting line is invalid (too many arguments to "test"):

      if [ 55 /etc/passwd -gt 0 ] ; then echo hi ; fi

    - the fix is to use input redirection to avoid the file name argument:
      
      $ x=$( wc -l </etc/passwd )     # input redirection avoids file name
      $ if [ $x -gt 0 ] ; then echo hi ; fi
      hi

The "test" command has useful file operators:

  -r -w -x  (read, write, execute)
  -f -d -e  (file, directory, exists)
  -s        (has size - not empty)

Test command negation:   if [ ! -r file ] ; then

Sending output to standard error (e.g. for error messages):

    echo 1>&2 "$0: This is an error message on standard error"

 - you can interpret "1>&2" to mean "redirect the output of this
   command line from unit 1 (stdout) to unit 2 (stderr)"

More vim (Chapter 9):

  - yank and put:   yy   and    p    and    P
  - replace one character: r