Lab46 Wiki

User Tools

Site Tools

You are here: start » haas » spring2022 » unix » projects » upf0
haas:spring2022:unix:projects:upf0

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
haas:spring2022:unix:projects:upf0 [2022/01/25 14:24] – [Get started] wedgehaas: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 146: 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 204: 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 219: 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 225: 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.1643120694.txt.gz · Last modified: 2022/01/25 14:24 by wedge

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki