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:57] – [Only specifying numeric pattern] wedge | haas:spring2018:unix:projects:spf0 [2018/03/14 18:30] (current) – [Specifications] wedge | ||
---|---|---|---|
Line 219: | Line 219: | ||
lab46: | 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 224: | 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 282: | 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 294: | 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 345: | 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 |