User Tools

Site Tools


haas:spring2022:unix:projects:upf0

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
haas:spring2022:unix:projects:upf0 [2021/09/20 23:04] – external edit 127.0.0.1haas:spring2022:unix:projects:upf0 [2022/03/01 19:58] (current) – [upf0steps] wedge
Line 18: Line 18:
 This project has us playing with various examples that will require regular use of these skills, for the purpose of throwing numbers and math operations together to produce desired results (and in desired composition). This project has us playing with various examples that will require regular use of these skills, for the purpose of throwing numbers and math operations together to produce desired results (and in desired composition).
  
 +It can be helpful to fully read and understand the instructions associated with resources. This can take the form of comments in a source code or configuration file, or even actual instructions. If you see conspicuously-named files hinting at some action that you can take, you may want to investigate said file to see if it might aid you in some capacity.
 =====Get started===== =====Get started=====
 This week's project has 2 points of origin. This week's project has 2 points of origin.
Line 49: Line 50:
   * pipemath-20170123-13.tar.gz   * pipemath-20170123-13.tar.gz
   * pipemath-20170201-09.tar.gz   * pipemath-20170201-09.tar.gz
 +  * pipemath-20210321-17.tar.gz
 +  * pipemath-20220401-02.tar.gz
  
-From visual inspection, you would select the "20170201-09" one, because the date it encodes (Feb 1st, 2017 at 9am) is the most recent in that group. You will find this to be a common practice with many software projects on the internet.+From visual inspection, you would select the "20220401-02" one, because the date it encodes (April 1st, 2022 at 2am) is the most recent in that group. You will find this to be a common practice with many software projects on the internet.
  
-Note, however, that visual inspection alone is not good enough for your steps file. New versions may be released, and your steps file needs to obtain the most recent version available. To facilitate this task, the latest and greatest version of pipemath will be listed in a file called LATEST (which you should see near the top of the directory index listing). You can make use of this file to assist you in automating the process of determining and downloading the latest version of the pipemath tools.+Note, however, that visual inspection alone is not good enough for your steps file. New versions may be released, and your steps file needs to obtain the most recent version available. To facilitate this task, the latest and greatest version of pipemath will be listed in a text file called "LATEST(which you should see near the top of the directory index listing). You can make use of this file to assist you in automating the process of determining and downloading the latest version of the pipemath tools.
  
 Once those two steps are complete, you can begin on the tasks listed in your **TASK** file. Once those two steps are complete, you can begin on the tasks listed in your **TASK** file.
Line 144: Line 147:
 Basically, each task#.cli can be its own script. If we were to execute it, the correct result should be produced. Basically, each task#.cli can be its own script. If we were to execute it, the correct result should be produced.
  
 +=====Selection=====
 +Occasionally during the automation of a task, you will have need for the computer to make a decision based on the state of a condition to decide how to proceed. We accomplish this via the **if** selection structure.
  
 +In bash, an **if** takes the following form:
 +
 +<code bash>
 +if [ condition ]; then
 +    statement(s)
 +fi
 +</code>
 +
 +The "condition" are valid arguments posed to the **<nowiki>[</nowiki>**(**1**) command, resulting in a true or false result.
 +
 +There are one or more statements within the body of the if (to be run in the event the result of the condition tests true), and the structure is terminated with the trailing **fi** (if spelled backwards).
 +
 +We also have the ability to react in the event the **if** condition tests false, and that is with an optional **else** statement (which is used 0 or 1 times per if, and must always follow the if):
 +
 +<code bash>
 +if [ condition ]; then
 +    statement(s)
 +else
 +    statement(s)
 +fi
 +</code>
 +
 +The **else** has no condition: it is a reaction to the previously tested condition being false.
 +
 +====conditions====
 +The conditions we pose to the computer must be such that resolve ultimately to a true or false result.
 +
 +Each condition can be unary or binary in nature, meaning we can directly check the state of one thing, or compare the relationship between two things.
 +
 +For example, the **-z** argument to **[**(**1**) tests for a NULL string. If we wanted to see if a variable as a result of some operation were NULL or populated, we could do:
 +
 +<code bash>
 +check=$(/usr/bin/who | grep 'jsmith12' | wc -l | grep '^1$')
 +if [ -z "${check}" ]; then
 +    statement(s) # do this if check is NULL
 +fi
 +</code>
 +
 +Note that we could also check the opposite. We can use the **!** symbol to require the opposite (NOT):
 +
 +<code bash>
 +check=$(/usr/bin/who | grep 'jsmith12' | wc -l | grep '^1$')
 +if [ ! -z "${check}" ]; then
 +    statement(s) # do this if check is NOT NULL
 +fi
 +</code>
 +
 +Comparing two strings, the two common scenarios we tend to care about is whether or not the two strings are equal or not equal:
 +
 +<code bash>
 +string1="blah"
 +string2="boop"
 +
 +if [ "${string1}" = "${string2}" ]; then
 +    statement(s) # do this in the event strings are equal
 +fi
 +
 +if [ ! "${string1}" = "${string2}" ]; then
 +    statement(s) # do this in the event strings are NOT equal
 +fi
 +</code>
 +
 +It should be stated that instead of negating the result, we could also just use an **else** clause:
 +
 +<code bash>
 +string1="blah"
 +string2="boop"
 +
 +if [ "${string1}" = "${string2}" ]; then
 +    statement(s) # do this in the event strings are equal
 +else
 +    statement(s) # do this in the event strings are not equal
 +fi
 +</code>
 +
 +As a matter of style (and to potentially avoid syntax/logic errors being committed), one should not pose a condition just for the sake of ensuring its opposite (ie no empty clauses).
 +
 +If comparing numerical values, especially in numerical contexts, we have a set of arguments we can choose from:
 +
 +  * **-eq** - is equal to
 +  * **-ne** - is not equal to
 +  * **-lt** - is less than
 +  * **-le** - is less than or equal to
 +  * **-gt** - is greater than
 +  * **-ge** - is greater than or equal to
 +
 +These of course are binary conditions, meaning we compare TWO variables to see if they possess the indicated relation (which results in a true or false result produced).
 +
 +=====Loops=====
 +When you have a section of code you would like to repeat some number of times, a loop can be used to achieve this.
 +
 +Here we will explore the **while** conditional loop. If an if statement can run 0 or 1 times, a while loop can run 0 or more.
 +
 +<code bash>
 +count=10
 +while [ "${count}" -gt 0 ]; do
 +    echo "count is: ${count}"
 +    let count=count-1
 +done
 +</code>
 +
 +A couple changes from the if syntax: we use **do** to open the body, and **done** to resolve it. There's also no else-type countercase logic available. The loop is either running, or it terminates.
 +
 +To be sure, we can also run while loops on string comparisons:
 +
 +<code bash>
 +value="true"
 +while [ ! "${value}" = "false" ]; do
 +    statement(s)
 +    if [ condition ]; then
 +        value="false"
 +    fi
 +    other_statement(s)
 +done
 +</code>
 =====upf0steps===== =====upf0steps=====
 You will once again be creating a steps file that can automate your project.  You will once again be creating a steps file that can automate your project. 
  
-As in previous projects, **upf0steps** will contain the steps you took from the point of copying the numbers suite and downloading the pipemath suite up until the submit step (hint: just run the task#.cli scripts within the steps script). +As in previous projects, **upf0steps** will contain the steps you took from the point of downloading the pipemath suite up until the submit step (hint: just run the task#.cli scripts within the steps script). 
-  * To clarify: YES, I want to see steps creating a project directory, copying and downloading files in question, extracting, compiling, installing, and then of course running each individual task#.cli script.+ 
 +  * To clarify: YES, downloading files in question, extracting, compiling, installing, and then of course running each individual task#.cli script.
  
 There are some additional constraints you need to keep in mind: There are some additional constraints you need to keep in mind:
Line 202: Line 323:
 78:upf0:final tally of results (78/78) 78:upf0:final tally of results (78/78)
 *:upf0:upf0steps has valid list of non-interactive instructions [4/4] *:upf0:upf0steps has valid list of non-interactive instructions [4/4]
-*:upf0:upf0steps only copies/alters files if USER matches [4/4]+*:upf0:upf0steps only modifies files if USER matches [4/4]
 *:upf0:upf0steps builds the various task#.cli files it runs [4/4] *:upf0:upf0steps builds the various task#.cli files it runs [4/4]
 *:upf0:upf0steps obtains the latest pipemath release from site [4/4] *:upf0:upf0steps obtains the latest pipemath release from site [4/4]
 *:upf0:upf0steps only displays specified STDOUT output [4/4] *:upf0:upf0steps only displays specified STDOUT output [4/4]
-*:upf0:upf0steps resiliently creates local project directory [4/4] +*:upf0:upf0steps errorlessly creates local project directory [4/4]
-*:upf0:upf0steps copies public dir data with absolute path [4/4]+
 *:upf0:upf0steps makes clear, effective use of wildcards [4/4] *:upf0:upf0steps makes clear, effective use of wildcards [4/4]
 *:upf0:upf0steps has descriptive why and how comments [4/4] *:upf0:upf0steps has descriptive why and how comments [4/4]
-*:upf0:upf0steps indentation used to promote scope and clarity [2/2]+*:upf0:upf0steps indentation used to promote scope and clarity [4/4]
 *:upf0:upf0steps defines and uses custom variables [4/4] *:upf0:upf0steps defines and uses custom variables [4/4]
 *:upf0:upf0steps uses command expansions to get information [4/4] *:upf0:upf0steps uses command expansions to get information [4/4]
Line 217: Line 337:
 *:upf0:all files are organized, clear, and easy to read [4/4] *:upf0:all files are organized, clear, and easy to read [4/4]
 *:upf0:task#.cli files output only correct, specified data [4/4] *:upf0:task#.cli files output only correct, specified data [4/4]
-*:upf0:task#.cli files use specified number tools by quantity [4/4]+*:upf0:task#.cli files use specified number tools by quantity [6/6]
 *:upf0:task#.cli files display no STDERR output [4/4] *:upf0:task#.cli files display no STDERR output [4/4]
 *:upf0:task#.cli files have solution within given constraints [4/4] *:upf0:task#.cli files have solution within given constraints [4/4]
Line 223: Line 343:
 </code> </code>
  
 +Additionally:
 +  * Solutions not abiding by **SPIRIT** of project will be subject to a 25% overall deduction
 +  * Solutions not utilizing descriptive why and how **COMMENTS** will be subject to a 25% overall deduction
 +  * Solutions not utilizing **INDENTATION** to promote scope and clarity will be subject to a 25% overall deduction
 +  * Solutions lacking **ORGANIZATION** and are not easy to read (within 90 char width) are subject to a 25% overall deduction
haas/spring2022/unix/projects/upf0.1632179086.txt.gz · Last modified: 2021/09/20 23:04 by 127.0.0.1