• any bugfixes or project updates will be posted here

Working with familiar data (from having created it a few projects ago), we will now pursue avenues of compliance with TASK file specifications, performing general analysis, comparing across semesters, and other metrics.

As is often the case, tasks we are given are not only meant to be accomplished, but also verified.

In the upf0 project, we explored and created various task#.cli files which were to be viable solutions to problems using the numbers and pipemath tools within stated constraints.

We explored automating aspects of the process in the upf0steps file.

Now, we will specifically be looking at logic to verify that the solutions generated comply with the stated requirements of each problem (ie reference the TASK file and confirm the solution falls within acceptable bounds).

What's more, comparing one solution to others, even comparing one class to another are important skills in data analysis, allowing us to better realize patterns, trends, and other behaviors of the data (and users providing it).

In the gtf0/ sub-directory of the UNIX Public Directory are a number of sub-directories named after various semesters; for example, you may see things like:

• spring2017/
• fall2017/
• spring2018/

Inside each of these directories is a set of additional directories, named numerically (ranging from 0 to some value, likely approaching 20).

And inside THAT directory you will potentially find all or some of the following:

• TASK
• task0.cli
• task1.cli
• task2.cli
• task3.cli
• task4.cli
• task5.cli
• task6.cli
• task7.cli

I say some, because it is possible some directories will lack the task#.cli files (denoting an incomplete or non-existent submission).

You will be referencing the specific TASK file in each directory, to calibrate any logic used to evaluate the results.

NOTE: You do NOT want to copy this data. Reference it. This would be an excellent application of variables.

In the particular TASK file, there are a set of 8 tasks (ranging from 0 to 7) the provide specifications of command-lines that were to have been constructed to produce the desired outcome via particular means.

There are fields such as:

• result: the final output desired from running the command-line contained in that task#.cli file.
• numbers: specifications on which of the numbers tools can be used in the solving of the problem.
• operations: specifications on which of the pipemath tools can be used in the solving of the problem.
• min_pipes: indicates the minimum number of pipes that MUST be present on the command-line to qualify as a valid solution.
• max_pipes: indicates the maximum number of pipes that MUST be present on the command-line to qualify as a valid solution.

All of these factors will need to be taken into account when determining the correctness and viability of a particular solution (and then to compare one solution's viability against that of others).

As was the case in upf0, the potential constraints are as follows:

• ANY: no restrictions, any in applicable category can be used
• ONLY: you are restricted to only those listed
• WITH_LIMITS: usually providing specific restrictions within an ANY domain
• EXCEPT: you are explicitly not allowed to use the listed; usually restricting an existing ANY domain

There may also be quantity limits on how many times you can use each number or operation. If so, such will be shown in parenthesis following the item in question.

As an example, we could have the following (formatted is it would appear in your TASK file):

task: 0
result: 4
numbers: ONLY(three(2), five, seven, nine)
operations: ANY
min_pipes: 2
max_pipes: ANY

With these in mind, we can set about solving this problem, using the tools in combination to arrive at the desired result.

A potential solution would be as follows:

lab46:~/src/unix/upf0$ seven | minus `three`
4
lab46:~/src/unix/upf0$ 

BUT, we see that the min_pipes requirement is 2, and we only have 1 here… so we'll need to come up with another solution.

How about:

lab46:~/src/unix/upf0$ three | minus `seven` | negate
4
lab46:~/src/unix/upf0$ 

There we go… still got our 4, but this time via the minimum required quantity of pipes.

In this case, we'll want to record our command-line in the appropriate place. Since this is task #0, we'll want to record it in a file called: task0.cli, which should basically just contain the command-line you ran, merely placed in a text file.

For example, if you cat the file, you should see the following:

lab46:~/src/unix/upf0$ cat task0.cli
three | minus `seven` | negate
lab46:~/src/unix/upf0$ 

Basically, each task#.cli can be its own script. If we were to execute it, the correct result should be produced.

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

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

There are some additional constraints you need to keep in mind:

• your script should not produce ANY STDERR output
• your script should ONLY produce STDOUT output in conformance with the below stated requirements. Any other output needs to be silenced.
• For each task, you'll want to display things as follows:
  • “Task X result is: #”
    • where X is the task number (0, 1, 2, etc.)
    • where # is the calculated output matching the TASK file result requested (ie, you must run your task#.cli script to produce this output).
      • note that the task#.cli output appears on the SAME line as the “Task X result is:” text, and there is a single space separating it from the colon.
• additionally, your upf0steps file will only create, alter files if run by you. If run by a user who is not you, skip the file manipulation and only output the results.
• you will be making use of a loop to drive the execution of your results (the “Task # result is: …”).

For example, a sample output of your upf0steps script should appear like follows (but your # values will of course be different based on your individual TASK file):

lab46:~/src/unix/upf0$ ./upf0steps
Task 0 result is: 13
Task 1 result is: 27
Task 2 result is: 32
Task 3 result is: 7
Task 4 result is: -4
Task 5 result is: 57
Task 6 result is: 2
Task 7 result is: 98
lab46:~/src/unix/upf0$ 

By successfully performing this project, you should have a set of task#.cli files (one for each task). You will want to submit these, along with a upf0steps file.

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

$ submit unix upf0 upf0steps task*.cli
Submitting unix project "upf0":
    -> upf0steps(OK)
    -> task0.cli(OK)
    -> task1.cli(OK)
    -> task2.cli(OK)
    -> task3.cli(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:upf0:final tally of results (78/78)
*:upf0:upf0steps has valid list of non-interactive instructions [4/4]
*:upf0:upf0steps only copies/alters files if USER matches [4/4]
*:upf0:upf0steps builds the various task#.cli files it runs [4/4]
*:upf0:upf0steps obtains the latest pipemath release from site [4/4]
*:upf0:upf0steps only displays specified STDOUT output [4/4]
*:upf0:upf0steps resiliently creates local project directory [4/4]
*:upf0:upf0steps copies public dir data with absolute path [4/4]
*:upf0:upf0steps makes clear, effective use of wildcards [4/4]
*:upf0:upf0steps has descriptive why and how comments [4/4]
*:upf0:upf0steps indentation used to promote scope and clarity [2/2]
*:upf0:upf0steps defines and uses custom variables [4/4]
*:upf0:upf0steps uses command expansions to get information [4/4]
*:upf0:upf0steps uses a loop to drive numbers in final output [4/4]
*:upf0:upf0steps automates the task when run [4/4]
*:upf0:all files are organized, clear, and easy to read [4/4]
*:upf0:task#.cli files output only correct, specified data [4/4]
*:upf0:task#.cli files use specified number tools by quantity [4/4]
*:upf0:task#.cli files display no STDERR output [4/4]
*:upf0:task#.cli files have solution within given constraints [4/4]
*:upf0:task#.cli files only have the solution command-line [4/4]