• any bugfixes or project updates will be posted here

In addition to the tools you're already familiar with, it is recommended you check out the following tools for possible application in this project (you may not need to use them in your solution, but they definitely offer up functionality that some solutions can make use of):

• basename(1)
• bc(1)
• cut(1)
• diff(1)
• grep(1)
• mktemp(1)
• sed(1)
• tr(1)
• wc(1)

To create two scripts that perform some operation in the domain of calculating digits of PI, and searching its digits for patterns of substrings.

PI is an important mathematical constant. It is used in various applications, and we often find ourselves making use of it.

But what about generating it? That's part of what this project seeks to have us explore.

We will also, once successfully generating pi out to a variable amount of digits, write a script to allow us to search those digits for numeric substring patterns.

There are various methods for calculating PI, which take varying amounts of processing power and time to perform, and have different levels of accuracy.

We will want to come up with a process that is accurate, yet perhaps also relatively simple to express.

You may want to check out the method using arctan to accomplish this:

lab46:~/src/unix/spf0$ echo "4*a(1)" | bc -lq
3.14159265358979323844

Here we see that the default precision of bc(1) is to scale to around 20 digits.

With that, if we check a database of PI digits (which I have conveniently stored on lab46, in the /usr/local/etc/pi.1000000 file), we can compare our results against the verified, correct results (note that the database omits the period '.' separating the 3 from the 14…, be sure to compensate for this):

lab46:~/src/unix/spf0$ cat /usr/local/etc/pi.1000000 | cut -c1-21
314159265358979323846

It would seem that all but the last value is correct. In which case, we'd want to strip that off and retain the valid component in our explorations.

It is your task to write 2 scripts; one will be responsible for generating a file containing calculated digits of PI (and you must perform the calculations… no skimping on this), and the other will use that produced data to search through the digits of PI in order to find occurrences of patterns. Further details follow:

You are to write a script, called and submitted by the name pigen (no extension, although it is to be a bash script, with proper shabang, comments, and solution).

By default, if you run the script by itself, it should calculate and produce (in a file in the current directory), a file by the name of pi.100.out, which will contain the first 100 digits of PI (lacking the period '.' that separates the 3 from the rest of the irrational number):

lab46:~/src/unix/spf0$ ./pigen
lab46:~/src/unix/spf0$ ls
pi.100.out  pigen
lab46:~/src/unix/spf0$ cat pi.100.out
3141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067
lab46:~/src/unix.spf0$ 

If you provide a command-line argument, it must be a valid numeric value between 1 and 2000, and will calculate that many digits of PI, saving it in a file pi.#.out, where # is the number of digits requested.

You also need to verify your results against the PI digit database on lab46 (do not copy this file… set a variable to it for easy access), and display the message “MISMATCH” if your calculated/processed results do NOT match the validated PI computation out to that indicated quantity of spaces.

Additionally:

• Your script is to only produce a pi.#.out file in the current directory.
  • ANY temporary files need to be created in (and subsequently removed from) the /tmp directory, of a relatively unique name autogenerated by the mktemp(1) tool.

Your second script will be called pigrep, and will perform searches on your pigen-generated pi.#.out files for specified patterns (numerical substrings) within the generated digits.

By default, if you run the script by itself, it should generate the following error:

lab46:~/src/unix/spf0$ ./pigrep
ERROR: must specify PATTERN
lab46:~/src/unix/spf0$ 

It will have online usage information, displayed when the 'help' option is provided anywhere on the pigrep command-line:

lab46:~/src/unix/spf0$ ./pigrep help

 pigrep - search available pi digits via regex for matches;
          must be part of pipeline (send PI digits in via STDIN)

   usage: pigrep [OPTION...] PATTERN

    note: if MAX variable is set, cap processing at that value

 options:

  atend - calculations are based on last digit of match
 byline - output one value per line (default is space-separated)
  drop3 - do not include leading 3 of pi (*3*14) in processing
 offset - determine offsets of matches (from start of digits)
   help - display this help and exit

lab46:~/src/unix/spf0$ 

Your script should also take the following arguments (in this order):

• required argument:
  • PATTERN: a string containing the numeric pattern you are looking for.
    • for example: '76'
• optional arguments:
  • atend: by default, offset calculations are based on the first (left-most) digit of the pattern; with this option, compute the offset based on the last (right-most) digit of the pattern
    • atend is meant to be used in conjunction with offset, by itself it does not alter default processing
  • byline: by default, matches are space-separated. With this option, display one match per line
  • drop3: do not include the leading 3 of PI in processing
  • offset: determine offsets of matches from start of digits
  • help: display usage information

Numerical arguments are to be given in decimal (base 10).

With any of these arguments validly provided, they should adjust the script's processing and output accordingly.

Also to keep in mind:

• Your script is not to produce any files as a result of operating.
  • If your solution calls for ANY temporary files, they need to be created in (and subsequently removed from) the /tmp directory, and be of a relatively unique name autogenerated by the mktemp(1) tool.

Some sample outputs follow:

In the event only the starting value is specified, assume a count of 16 (so display 16 values, starting at the starting value).

For example:

lab46:~/src/unix/pwn0$ ./pwn0.sh 12
   base 2 |   base 8 |   base10 |   base16 |
----------+----------+----------+----------+
     1100 |       14 |       12 |        C |
     1101 |       15 |       13 |        D |
     1110 |       16 |       14 |        E |
     1111 |       17 |       15 |        F |
    10000 |       20 |       16 |       10 |
    10001 |       21 |       17 |       11 |
    10010 |       22 |       18 |       12 |
    10011 |       23 |       19 |       13 |
    10100 |       24 |       20 |       14 |
    10101 |       25 |       21 |       15 |
    10110 |       26 |       22 |       16 |
    10111 |       27 |       23 |       17 |
    11000 |       30 |       24 |       18 |
    11001 |       31 |       25 |       19 |
    11010 |       32 |       26 |       1A |
    11011 |       33 |       27 |       1B |
lab46:~/src/unix/pwn0$ 

Evaluation will be based on correctness of values as well as on formatting/spacing.

You'll notice that everything lines up and is positioned similarly:

• each column exists within 10 characters of on-screen real estate:
  • 8 characters for actual value display,
  • with one space padding either side
• columns are separated with a '|' symbol, appended to the right edge of the column (effectively making each column 11 characters wide).
  • note that the rightmost column is ended with this '|'.
• there is a heading/header at the top of the output table, and it uses a '+' to “connect” the horizontal and vertical lines being drawn
  • The dashes and vertical bars set up an ASCII art-like table pattern that helps make the data more readable.
• The values are right justified with each column
  • justification is essential. Everything should line up on its respective right margin.
• base headings are right justified, with a 2 spaces being allocated for reference of the base:
  • you'll see “base 2” vs. “base16”; your script needs to accommodate this.
• 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. Some examples:
  • starting value is a valid (whole) number
    • if less than 0, or greater than 255, needs to be capped to whichever extreme it exceeds
      • 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, etc.) should be silently dropped/ignored.
• 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
• your script needs to commence with a proper shabang to bash; your script needs to end with an “exit 0” at the very end
• comments and indentation are required and necessary
  • comments should explain how or why you are doing something
  • indentation should be consistent throughout the script
  • indentation is to be no less than 3 on-screen spaces (I recommend tabstops of 4).
• continuing with our shell scripting, your script will need to employ in a core/central way:
  • variables
  • command expansions
  • regular expressions
  • if statements
  • loops
  • at least 1 function (use function keyword to identify)
• your logic needs to:
  • flow (one thing leads into the next, as best as possible)
  • make sense within the given context
  • avoid redundancy (make a function instead of maintaining multiple copies of code)
  • be understood by you (no grabbing snippets that seem to “work” from the internet)
    • 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, and it isn't in violation of other aspects, I'll know you are in control of things)

To be sure, I'll be checking to make sure you solution follows the spirit of what this project is about (that you implement functional, flowing logic utilizing the tools and concepts we've learned, in an application that helps demonstrate your comprehension). Don't try to weasel your way out of this or cut corners. This is an opportunity to further solidify your proficiency with everything.

The spirit of the project embodies many aspects we've been focusing on throughout the semester:

• recognizing patterns to employ effective solutions in problem solving
• utilizing concepts and tools covered
• demonstrating comprehension of concepts, tools, and problems
• employing concepts in knowledgeable and thoughtful manner
• following instructions
• implementing to specifications
• utilizing creativity
• being able to control solution via consistent, clear, and organized presentation

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.

Cutting corners, avoiding work, skimping on functionality, cheating through getting others to do work for you or finding pre-packaged “answers” on the internet violates the spirit of the project, for they betray your ability to pull off the task on your own.

I would also like it if you provided an inventory of what functionality is lacking or out of spec when you submit the project. The better you can describe your deviations from stated requirements, the more forgiving I may be during evaluation (versus trying to hide the shortcomings and hoping I do not discover them).

The more fluent you are in describing your shortcomings on accomplishing the project (ie “I didn't know how to do this” is far from fluent), the better I will be able to gauge your understanding on a particular aspect.

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).

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, which contains a list of filenames (output0 - outputF) and the pwn0.sh script command-line used to generate the output found in those files.

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, it should offer up some assistance in helping you broaden your view of troubleshooting scenarios.

By successfully performing this project, you should have a fully functioning script by the name of pwn0.sh, which is all you need to submit for project completion (no steps file, as your “steps” file IS the script you wrote).

To submit this project to me using the submit tool, run the following command at your lab46 prompt:

$ submit unix pwn0 pwn0.sh
Submitting unix project "pwn0":
    -> pwn0.sh(OK)

SUCCESSFULLY SUBMITTED

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:

78:pwn0:final tally of results (78/78)
*:pwn0:pwn0.sh on help displays informative usage and exits [4/4]
*:pwn0:pwn0.sh effectively utilizes variables in operations [4/4]
*:pwn0:pwn0.sh effectively utilizes command expansions [4/4]
*:pwn0:pwn0.sh effectively utilizes regular expressions [4/4]
*:pwn0:pwn0.sh effectively utilizes selection statements [4/4]
*:pwn0:pwn0.sh effectively utilizes looping structures [4/4]
*:pwn0:pwn0.sh effectively utilizes functions in script [4/4]
*:pwn0:pwn0.sh is a proper bash script with shabang and exit [4/4]
*:pwn0:pwn0.sh parses command-line arguments as appropriate [4/4]
*:pwn0:pwn0.sh accurately displays values in proper alignment [4/4]
*:pwn0:pwn0.sh accurately displays values in requested bases [4/4]
*:pwn0:pwn0.sh accurately displays values in specified range [4/4]
*:pwn0:pwn0.sh range logic flexibly works forward and reverse [4/4]
*:pwn0:pwn0.sh iterates as appropriate in given scenarios [4/4]
*:pwn0:pwn0.sh includes additional bases as requested [4/4]
*:pwn0:pwn0.sh omits specified bases as requested [4/4]
*:pwn0:pwn0.sh properly manages input violations [4/4]
*:pwn0:pwn0.sh operates according to specifications [5/5]
*:pwn0:pwn0.sh logic is organized and easy to read [5/5]

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