This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
haas:spring2022:unix:projects:upf0 [2022/02/28 14:57] – [Process] wedge | haas:spring2022:unix:projects:upf0 [2022/03/01 19:58] (current) – [upf0steps] wedge | ||
---|---|---|---|
Line 162: | Line 162: | ||
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). | 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 option | + | We also have the ability to react in the event the **if** condition tests false, and that is with an optional |
<code bash> | <code bash> | ||
Line 197: | Line 197: | ||
</ | </ | ||
+ | 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 254: | Line 323: | ||
78: | 78: | ||
*: | *: | ||
- | *: | + | *: |
*: | *: | ||
*: | *: | ||
*: | *: | ||
- | *: | + | *: |
- | *: | + | |
*: | *: | ||
*: | *: | ||
- | *: | + | *: |
*: | *: | ||
*: | *: | ||
Line 269: | 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 275: | 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 |