This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
haas:spring2022:unix:projects:upf0 [2021/09/20 23:04] – external edit 127.0.0.1 | haas: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 |
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 | ||
+ | </ | ||
+ | |||
+ | The " | ||
+ | |||
+ | 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 | ||
+ | </ | ||
+ | |||
+ | 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=$(/ | ||
+ | if [ -z " | ||
+ | statement(s) # do this if check is NULL | ||
+ | fi | ||
+ | </ | ||
+ | |||
+ | Note that we could also check the opposite. We can use the **!** symbol to require the opposite (NOT): | ||
+ | |||
+ | <code bash> | ||
+ | check=$(/ | ||
+ | if [ ! -z " | ||
+ | statement(s) # do this if check is NOT NULL | ||
+ | fi | ||
+ | </ | ||
+ | |||
+ | 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=" | ||
+ | string2=" | ||
+ | |||
+ | if [ " | ||
+ | statement(s) # do this in the event strings are equal | ||
+ | fi | ||
+ | |||
+ | if [ ! " | ||
+ | statement(s) # do this in the event strings are NOT equal | ||
+ | fi | ||
+ | </ | ||
+ | |||
+ | It should be stated that instead of negating the result, we could also just use an **else** clause: | ||
+ | |||
+ | <code bash> | ||
+ | string1=" | ||
+ | string2=" | ||
+ | |||
+ | if [ " | ||
+ | statement(s) # do this in the event strings are equal | ||
+ | else | ||
+ | statement(s) # do this in the event strings are not equal | ||
+ | fi | ||
+ | </ | ||
+ | |||
+ | As a matter of style (and to potentially avoid syntax/ | ||
+ | |||
+ | 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 [ " | ||
+ | echo "count is: ${count}" | ||
+ | let count=count-1 | ||
+ | done | ||
+ | </ | ||
+ | |||
+ | A couple changes from the if syntax: we use **do** to open the body, and **done** to resolve it. There' | ||
+ | |||
+ | To be sure, we can also run while loops on string comparisons: | ||
+ | |||
+ | <code bash> | ||
+ | value=" | ||
+ | while [ ! " | ||
+ | statement(s) | ||
+ | if [ condition ]; then | ||
+ | value=" | ||
+ | fi | ||
+ | other_statement(s) | ||
+ | done | ||
+ | </ | ||
=====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: | 78: | ||
*: | *: | ||
- | *: | + | *: |
*: | *: | ||
*: | *: | ||
*: | *: | ||
- | *: | + | *: |
- | *: | + | |
*: | *: | ||
*: | *: | ||
- | *: | + | *: |
*: | *: | ||
*: | *: | ||
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] | ||
*: | *: | ||
- | *: | + | *: |
*: | *: | ||
*: | *: | ||
Line 223: | Line 343: | ||
</ | </ | ||
+ | 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 |