CS 279 - Week 5 Lecture 1 - 2022-09-19

TODAY WE WILL
*   announcements
*   more testing tidbits
*   intro to environment variables
*   (if time) intro to processes and jobs
*   (if time) standard files and redirection
*   prep for next class

*   CS Club - Coding Cafe will be the FIRST and THIRD
    Tuesdays of each month -- first is TOMORROW -
    4:30 - 6:00 pm, meet in BSS 302 (and may spread out
    from there)
    *   Coding Cafe -- a place to meet with other students,
        collaborate and commiserate, and work on homeworks
	and coding projects!

*   Exam 1 - is Wednesday, Sept 28
    *   will review for that on Wednesday (Sept 21)

    *   we'll also discuss Wednesday when final attempts
        at HWs 1-3 will be due, so example solutions
	can be posted for Exam study

=====
*   more testing-construct info!
    *   (from The Linux Documentation Project,
        tldp.org)

    *   (( ... ))
        this construct evaluates and tests
	NUMERICAL expressions!

        ...so, can see that works nicely for
	   a "classic"-style for loop!

        for ((i=0; i<100; i++))
	do
	    ....
	done

    *   notes that operations like < > == work in
        (( ... ))

*   The [[ ... ]] is the EXTENDED test command,
    adopted from ksh88 <-- 1988 version of Korn Shell?

    *   sounds like it is more robust?
    *   TLDP claims that && || < > work better in
        [[ ... ]] than [ ... ]...?

    *   an operator that definitely works
        in [[ ]] but not [ ]:   =~

        [[ <string> =~ <regular-expression> ]]

        ...will be true if <string> matches
	the given <regular-expression>

        More on regular expressions after Exam 1!

*   some of the existing tests:
    -e <filename>  # returns true if <filename> exists
    -f <filename>  # returns true if <filename>
                   #     is a "regular" file (not
		   #     a directory file, not
		   #     a device file)
    -d <filename>  # returns true if <filneame>
                   #     is a directory file
    (and more!)
    see: https://tldp.org/LDP/abs/html/fto.html

*   BEWARE - be prepared for spaces in filenames,
    and for empty arguments when they occur...!

    *   some advice I have seen:

        if you put double-quotes around
	filename variables in tests,
	that might save you headaches when
	there are spaces in filenames...

        if [ $filename = foo ]

        better:
	if [ "$filename" = foo ]

        ...just keep this in mind;

====
Environment variables!
====
*   each process has a collection of
    environment variables associated with it

    *   these can be queried or set by the process

    *   and are inherited by its subprocesses

*   tend to be written in all-uppercase!

    TERM - tends to be set to the terminal type

*   you can see the values of environment variables
    currently in effect with the env command

*   When you start a new process as the child
    of another,
    UNIX/Linux sets the environment variables
    of the child process to a COPY of those
    of its parent process
    *   from then on, the environment variables
        of the child and parent are INDEPENDENT

    *   when a process terminates, its environment
        variables disappear and any changes to
	them are lost

    *   demo: harmless-to-call

*   There is an environment variable named
    SHELL that lets you see your login shell
    "the shell called on your behalf when you
    log in"

    *   you can execute a different shell
        (within your current shell process)
	with the exec command:

	exec ksh

	...for example

        You can use $0 to see what shell
	you are CURRENTLY running
	(since even when you run exec,
	you aren't changing the name of
	your default login shell in SHELL)

*   so we know shells are command-line interpreters,
    and they also provide a programming language
    for writing SHELL SCRIPTS
    *   these scripts are also interpreted
        by the apppropriate shell

    *   some advantages:
        *   might save time on common collections
	    on commands (run the script instead of
	    typing the commands repeatedly
	*   they are (relatively) easy to write
	    and install

    *   some disadvantages:
        *   they do lack low-level programming
	    featured such as pointers

        *   ...and high-level features such as
	    modularization, classes, user-definable
	    data types

        *   they are not particularly efficient
	    since they are interpreted rather than
	    compiled

    *   (some UNIX/Linux commands may be
        shell scripts, but some are C or C++
	or other-compiled-language programs...)