This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
haas:spring2018:unix:projects:spf0 [2018/03/14 16:14] – [Only specifying starting value] wedge | haas:spring2018:unix:projects:spf0 [2018/03/14 18:30] (current) – [Specifications] wedge | ||
---|---|---|---|
Line 145: | Line 145: | ||
====Only specifying numeric pattern==== | ====Only specifying numeric pattern==== | ||
- | In the event only a pattern is provided, search through the PI data for the provided pattern, displaying each match. | + | In the event only a pattern is provided, search through the PI data for the provided pattern, displaying each match to STDOUT. |
For example: | For example: | ||
Line 155: | Line 155: | ||
</ | </ | ||
+ | ====one result per line==== | ||
+ | Using the **byline** option, instead of displaying results horizonally, | ||
+ | |||
+ | <cli> | ||
+ | lab46: | ||
+ | 26 | ||
+ | 26 | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | ====compute offsets from start of digits==== | ||
+ | The **offset** argument will, instead of displaying the numeric matches (which, aside from counting are of dubious value) will display how many digits away from the start of the PI digits the pattern resides. | ||
+ | |||
+ | <cli> | ||
+ | lab46: | ||
+ | 7 22 | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | With an example like this, we should easily be able to verify its correctness: | ||
+ | |||
+ | <cli> | ||
+ | lab46: | ||
+ | 314159265358979323846264338327950288419716939937510582097494459230781640628620899862803482534211706798214808651328230664 | ||
+ | lab46: | ||
+ | 2626 | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | ====mixing options (offset, byline)==== | ||
+ | And we can mix options (in any order): | ||
+ | |||
+ | <cli> | ||
+ | lab46: | ||
+ | 7 | ||
+ | 22 | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | ====Using atend with offset==== | ||
+ | The **atend** option, issued by itself, has no impact on operations: | ||
+ | |||
+ | <cli> | ||
+ | lab46: | ||
+ | 26 26 | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | So we need to combine it with the **offset** option to make an impact: | ||
+ | |||
+ | <cli> | ||
+ | lab46: | ||
+ | 8 23 | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | ====dropping the leading 3==== | ||
+ | With the **drop3** option, we merely exclude the leading 3 of pi from our calculations. This should result in everything being "off by one" from previous outputs (with any combination of arguments): | ||
+ | |||
+ | <cli> | ||
+ | lab46: | ||
+ | 7 22 | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | ====Using MAX to limit processing==== | ||
+ | Sometimes, a pattern may produce an untenable quantity of results. We may wish to restrict it, and can do so with the aid of setting the **MAX** variable. | ||
+ | |||
+ | Take this request, which produces numerous results: | ||
+ | |||
+ | <cli> | ||
+ | lab46: | ||
+ | 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | We can cut that down to a smaller quantity by setting MAX accordingly (let's say, limit to 4 matches): | ||
+ | |||
+ | <cli> | ||
+ | lab46: | ||
+ | 2 2 2 2 | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | You could also **export** MAX, mitigating the need to manually specify it for each run. | ||
=====Specifications===== | =====Specifications===== | ||
Evaluation will be based on correctness of values as well as on formatting/ | Evaluation will be based on correctness of values as well as on formatting/ | ||
Line 160: | Line 245: | ||
You'll notice that everything lines up and is positioned similarly: | You'll notice that everything lines up and is positioned similarly: | ||
- | * each column exists within 10 characters of on-screen real estate: | + | * groupwork! This project is specifically designed to be performed in groups. |
- | * 8 characters for actual value display, | + | * I want to see groups ranging from a minimum of 2 people, to a maximum of 4 people. Any less and any more are not allowed. |
- | * with one space padding either side | + | * furthermore, groups |
- | * columns are separated with a '< | + | * ranks 1 and 2 are specifically and uniquely exempt from this restriction (ie they can be part of the same group, if they were to choose to be a group of 2). Otherwise, same rank spacing still applies. |
- | * note that the rightmost column is ended with this '< | + | * groups |
- | * there is a heading/ | + | * EVERY group member needs to be identified in your scripts (in a comment listing everyone). |
- | * The dashes and vertical bars set up an ASCII art-like table pattern that helps make the data more readable. | + | * EVERY group member needs to be familiar |
- | * The values are right justified | + | * EVERY group member needs to submit |
- | * justification is essential. Everything should line up on its respective right margin. | + | * in the event you feel other group members have not lived up to their obligations, |
- | * base headings are right justified, with a 2 spaces being allocated for reference | + | * EVERY group member needs to do an approximately equal portion |
- | * you'll see "base 2" vs. " | + | |
- | * You are to literally print out no more than 2 consecutive spaces at a time in your output statements. If you need more, use one of the formatting tools to generate spaces for you (**printf(1)** may be able to help you with this). | + | * You need to check your arguments to ensure they are present and valid. |
- | * You need to check your arguments to ensure they are present and valid. | + | * all mentioned arguments implementing their indicated functionality |
- | * starting value is a valid (whole) number | + | * help takes priority over other options |
- | * if less than 0, or greater than 255, needs to be capped to whichever extreme it exceeds | + | * atend has no appreciable impact unless offset is also specified |
- | * if -4, cap to 0 | + | |
- | * if 300, cap to 255 | + | |
- | * ending value is a valid (whole) number | + | |
- | * if less than 0, or greater than 255, needs to be capped to whichever extreme it exceeds | + | |
- | * if -8, cap to 0 | + | |
- | * if 420, cap to 255 | + | |
* any invalid arguments (nonsensical value in place of starting value, invalid base specification, | * any invalid arguments (nonsensical value in place of starting value, invalid base specification, | ||
- | * default starting value is 0, default ending value is 15. If nothing else is validly provided, these are the values the script should run with. | ||
- | * if starting and ending values are the same, the script will display just one line of number output (in addition to the header). | ||
* if lacking any bases to display, silently exit | * if lacking any bases to display, silently exit | ||
- | * your script needs to commence with a proper **shabang** to bash; your script needs to end with an " | + | * your script needs to commence with a proper **shabang** to run using bash; your script needs to end with an " |
* comments and indentation are required and necessary | * comments and indentation are required and necessary | ||
* comments should explain how or why you are doing something | * comments should explain how or why you are doing something | ||
- | * indentation should be consistent throughout the script | + | * indentation should be consistent throughout the script |
* indentation is to be no less than 3 on-screen spaces (I recommend tabstops of 4). | * indentation is to be no less than 3 on-screen spaces (I recommend tabstops of 4). | ||
- | * continuing with our shell scripting, your script | + | * continuing with our shell scripting, your scripts |
* variables | * variables | ||
+ | * command-line argument parsing and usage | ||
+ | * command-line pipelines | ||
* command expansions | * command expansions | ||
* regular expressions | * regular expressions | ||
- | * if statements | + | * conditional/ |
* loops | * loops | ||
- | * at least 1 function (use **function** keyword to identify) | ||
* your logic needs to: | * your logic needs to: | ||
* flow (one thing leads into the next, as best as possible) | * flow (one thing leads into the next, as best as possible) | ||
* make sense within the given context | * make sense within the given context | ||
- | * avoid redundancy | + | * avoid redundancy |
- | * be understood by you (no grabbing snippets that seem to " | + | * be understood by you, and everyone in your group (no grabbing snippets that seem to " |
* if you gain inspiration from some external resource, please cite it | * if you gain inspiration from some external resource, please cite it | ||
* comments are a great way of demonstrating understanding (if you explain the why and how effectively, | * comments are a great way of demonstrating understanding (if you explain the why and how effectively, | ||
Line 218: | Line 296: | ||
* utilizing creativity | * utilizing creativity | ||
* being able to control solution via consistent, clear, and organized presentation | * being able to control solution via consistent, clear, and organized presentation | ||
+ | * approximately equal involvement and impact of all group members on the brainstorming and development of the finished scripts. | ||
- | Basically: I want your solution to be the result of an honest, genuine brainstorming process where you have (on your own) figured out a path to solving the problem, you have dabbled and experimented and figured things out, and you can command the concepts and tools with a fluency enabling you to pull off such a feat. Your solution should demonstrate the real learning that took place and experience gained. | + | Basically: I want your solution to be the result of an honest, genuine brainstorming process where you have figured out a path to solving the problem, you have dabbled and experimented and figured things out, and you can command the concepts and tools with a fluency enabling you to pull off such a feat. Your solution should demonstrate the real learning that took place and experience gained. |
Cutting corners, avoiding work, skimping on functionality, | Cutting corners, avoiding work, skimping on functionality, | ||
Line 230: | Line 309: | ||
This can be in the form of comments in your script, or even a separate file submitted at time of submission (if a file, be sure to make mention of it in your script so I can be sure to look for it). | This can be in the form of comments in your script, or even a separate file submitted at time of submission (if a file, be sure to make mention of it in your script so I can be sure to look for it). | ||
- | =====Verification===== | ||
- | To assist you in verifying output compliance, I have generated a set of sample script outputs and placed them in the public directory for this project. | ||
- | |||
- | There you will find a file by the name of **outputlist**, | ||
- | |||
- | Using these files, you can check the functionality of your script in a number of operating conditions, to verify that it is indeed working as it should be. While this isn't likely to cover the full spectrum of possibilities, | ||
=====Submission===== | =====Submission===== | ||
- | By successfully performing this project, you should have a fully functioning | + | By successfully performing this project, you should have a fully functioning |
To submit this project to me using the **submit** tool, run the following command at your lab46 prompt: | To submit this project to me using the **submit** tool, run the following command at your lab46 prompt: | ||
<cli> | <cli> | ||
- | $ submit unix pwn0 pwn0.sh | + | $ submit unix spf0 pigen pigrep |
- | Submitting unix project "pwn0": | + | Submitting unix project "spf0": |
- | -> pwn0.sh(OK) | + | -> pigen(OK) |
+ | -> pigrep(OK) | ||
SUCCESSFULLY SUBMITTED | SUCCESSFULLY SUBMITTED | ||
</ | </ | ||
- | You should get some sort of confirmation indicating successful submission | + | You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches. |
I'll be looking for the following: | I'll be looking for the following: | ||
< | < | ||
- | 78:pwn0:final tally of results (78/78) | + | 26:spf0:final tally of results (26/26) |
- | *:pwn0:pwn0.sh on help displays informative usage and exits [4/4] | + | *:spf0:scripts effectively utilize variables in operations |
- | *:pwn0:pwn0.sh | + | *:spf0:scripts |
- | *:pwn0:pwn0.sh | + | *:spf0:scripts |
- | *:pwn0:pwn0.sh | + | *:spf0:scripts |
- | *:pwn0:pwn0.sh | + | *:spf0:scripts |
- | *:pwn0:pwn0.sh | + | *:spf0:scripts |
- | *:pwn0:pwn0.sh effectively utilizes functions in script [4/4] | + | *:spf0:scripts are proper bash scripts |
- | *: | + | *:spf0:pigrep |
- | *:pwn0:pwn0.sh parses command-line arguments as appropriate [4/4] | + | *:spf0:pigrep |
- | *: | + | *:spf0:scripts properly manage input violations |
- | *:pwn0:pwn0.sh | + | *:spf0:pigen operates according to specifications |
- | *: | + | *:spf0:pigrep |
- | *: | + | *:spf0:script |
- | *: | + | |
- | *: | + | |
- | *:pwn0:pwn0.sh omits specified bases as requested | + | |
- | *:pwn0:pwn0.sh properly manages input violations | + | |
- | *:pwn0:pwn0.sh | + | |
- | *:pwn0:pwn0.sh | + | |
</ | </ | ||
Line 281: | Line 349: | ||
* Solutions not utilizing descriptive why and how comments 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 not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction | ||
+ | * Solutions not done in a valid group will be subject to a 25% overall deduction |