UNIX FALL2026 EOCE

The End of Course Experience (eoce) satisfies the fourth discrete grading component of the course. It is meant to evaluate your knowledge and understanding gained through the semester.

Unlike the regular weekly projects, the purpose of which is to promote a learning and understanding of the concepts of the course, this EoCE is meant more as a demonstration of your proficiency in understanding and utilizing the concepts and skills obtained, showing me how productive you can be with the experiences gained.

RULES

Presented within will be various activities evaluating your knowledge and experience gained this semester. In places where you are able, the more you write (ie comment) and explain topics the better the chance you will have of receiving full credit (and alternatively, the more credit you will receive should something defer correctness).

Unless otherwise specified, the components on this experience are open resource with the exception of other individuals. In that respect, it is CLOSED PERSON. This means you are not to communicate with other people (either in the class or otherwise), in real life or electronically. Use your own knowledge, use your own skills, and use your own ability to access the allowed resources to aid you in coming up with your well thought out responses to each activity.

You are allowed, and expected, to seek clarification on any activity by asking me. But the aim here is to evaluate what you have learned, so do not expect tutoring. Any help should be prompted by a well-asked question. The better and more informed your questions, the better my responses MAY be. In many ways, I designed this EoCE premised on each and every one of you interacting with me through the asking of informed questions. Those that do not take advantage of asking such calibre of questions and instead end up struggling, please know that you're doing this wrong. But also know that, the aim here is for you to accomplish the various tasks through your own understanding of the task and concepts at hand, and not to outsource your thinking and remembering to others.

You are to all of the available items. Submission is to be as a submitted archive to the usual and appropriate places: the 'pctF' project submitted via its usual process, the other items will be part of the eoce project that you would have grabited.

To maximize any credit received (or to minimize points lost), optimize your submission for an organized and easy-to-read presentation of information that conforms with each section's stated guidelines. In the case of programs or scripts written, ensure that you are following proper and consistent commenting/documentation and indentation practices. Use well-named variables (at least 4 symbols long), and be mindful of how your particular files submitted will appear on a reasonably-sized terminal (most of my terminals are 80-90 characters wide), should that be the contextually relevant destination of output.

The EoCE is worth 26 points of your overall grade (projects (52) + participation (13) + notes (13) + eoce (26) = 104), representing a distinct fourth category within the grading policy of the course (Projects, Journal, Participation, and EoCE).

FINALS WEEK AVAILABILITY

While some classes are allocated a specific meeting time during finals week, I make all such times available should you be free and have questions. As such, finals week in CHM123 will look something like this:

Thursday, December 10th, 2026 from 08:00AM-11:00AM
Thursday, December 10th, 2026 from 02:30PM-05:30PM
Friday, December 11th, 2026 from 02:30PM-05:30PM
Tuesday, December 15th, 2026 from 11:15AM-02:15PM

Do note, the discord remains available for questions, and there is no need for you to be physically present at a given time during finals week. These are merely resources available to you should you wish to utilize them in the appropriate manners they are available to be used.

GRABIT

There is a grabit available for the EoCE. It would house the code for the various programming sections. The letter division is transacted via its own pctF project.

CONTENT

CALENDAR SCRIPT

Your task here is to implement a bash script solution of a real life process: the mental math trick of determining what day of the week January 1 of any given year (in the 21st century) falls on.

You may safely assume that all requests will be for days in the 21st century (2000-2099)

Background

Mental Math constitutes an intersection of mental tricks and math- instead of utilizing a purely math-only solution, textual manipulations or simplifications in the computational process may take place enabling an individual to, once having learned the process, solve such problems in their head, and typically without the use of a calculating device.

The process in this case is one of simple (reduced) multiplication and mapping against a table. To wit:

Day values

For this trick to work, we need to be familiar with the following table (a map of days to numeric values):

Sun	Mon	Tue	Wed	Thu	Fri	Sat	Sun
0	1	2	3	4	5	6	7

NOTE: Depending on how you implement your algorithm, you may find your approach prefers 7s OR 0s for your Sunday value… you aren't going to be encountering them at random. Once you work through your approach, you will discover which one you end up with.

Calculating day of the week based on year

Okay, time for the magic:

Let us try it on January 1st, 2014.

Step 1: Obtain last two digits of the year

In our example, we're working with 2014, the last two digits are therefore: 14

You should be able to come up with a means of extracting this information in your program.

NOTE: You are to input the 4-digit year as input into your bash script.

Step 2: Compute 25% (drop the decimal)

Even this is something we can do in our heads. I can think of two approaches right off the bat:

Approach 1: 10 + 10 + 5

10% percent of anything is merely moving the decimal over one place to the left. 10% of 54 is 5.4

For our 2014 example, 10% of 14 is therefore 1.4

So we need two 10 percents… 1.4 + 1.4 = 2.8

Finally, 5% is half of 10% (half of 1.4 is 0.7), so 1.4 + 1.4 + 0.7 = 3.5

But, since we do not care about the decimal at this end point, we drop it and are left with just 3.

Approach 2: half of half

25% is a convenient value for us with respect to 100, allowing this optimized approach to work.

Half of 100 is 50 (50%)
Half of 50 is 25 (25%) – hence the "half of a half"

So, 14 cut in half is 7.

7 cut in half is 3.5.

Once again, dropping the decimal yields 3.

Step 3: Add 25% to year value

Once we have our 25% value, go and add it back to our two-digit year value:

  14 + 3 = 17

Step 4: Subtract the largest fitting multiple of 7

Why multiple of 7? Seven days in a week.

Some multiples of 7:

|——|——|——|——|——|——|——|——| | 0 | 7 | 14 | 21 | 28 | 35 | 42 | 49 | |——|——|——|——|——|——|——|——|

So, with a value of 17, what is the largest multiple of 7 that is still less than (or equal to) 17?

Hopefully you identified the 14 as the likely candidate.

  17 - 14 = 3

Step 5: Look up day in table

We ended up with a 3 as the result for January 1st, 2014.

Go and reference the 3 from that table… what day do we get? Does it match the actual day of the week for January 1st, 2014? We can verify it with the cal command:

  $ cal 01 2014
      January 2014
  Su Mo Tu We Th Fr Sa
            1  2  3  4
   5  6  7  8  9 10 11
  12 13 14 15 16 17 18
  19 20 21 22 23 24 25
  26 27 28 29 30 31

  lab46:~$

Pretty neat, eh?

Exception: Leap Years

In the event of a leap year, we simply subtract 1 from the 25% value, and continue on as usual.

Makes sense, right? Leap years add a day, so something ends up being "off by one".

Script

It is your task to write a bash script that will use the above method to determine the day of the week any given January 1st in the 21st century falls on.

Your script should:

prompt the user for the four digit year (input)
perform the task (process)
display the final value (output)

Execution

Here is a sample run of the script:

  Which year: 2014
  January 1st, 2014 falls on: Wednesday

The execution of the script is short and simple- obtain the input, do the processing, produce the output, and then terminate.

Output Specifications

Your program must output as follows:

Input prompts, and everything else except the actual day of the week should be output to STDERR
The calculated, fully-spelled-out day of the week (and only the day name) needs to be displayed to STDOUT
The output MUST contain the "January 1st, YEAR" string
- YEAR must be all 4 digits, exactly as input by the user
The calculated day of the week must be fully spelled out and correct, with the first letter capitalized, remaining letters lowercase.

Verification

One of the tests I will perform for output compliance of your code will involve comparing your script's output against a range of input values, to see if they all output in conformance with project specifications.

You can check your results by typing in the following at the prompt:

  $ ./verify

If all aligns, you will see a lack of error messages output to the screen. However, if your output or formatting is off by even one byte, you will see a "MISMATCH".

The resultant script MUST be well-organized, easy-to-read, consistently indented visually showing the encapsulated levels of logic, and be thoroughly commented to explain each significant step of the process.

REVERSE ENGINEER AND DOCUMENT A SCRIPT

Reference and modify the files in the revE/ directory.

Here you will find a script, stripping of proper formatting and comments; it performs a task that you must figure out and document (in the form of comments), as you also restore proper indentation.

Note that the files in their current form, while they perform an operation, are not in the proper form needed for submission (namely, laying out in an organized, easy-to-read, consistently indented, and well-commented fashion; that is something you may need to figure out).

What is going on here? Both on a global (what functionality the script, when properly invoked, provides) and also more local (what are particular operations within the script doing to aid in performing the overall process).

In your finished, submitted product, no line in the script should span longer than 90 characters. This includes both script logic and your comments.

with the exception of "then" and "do" statements, no other commands can be separated by semi-colons
if there are any naming manipulations needed on the script, create them as symbolic links against the main script.
submit with the rest of the eoce, by running "make submit" in the base directory.

PCTF

Your task here is a familiar one: a letter division, just as we've encountered all semester. Only, this one is of the solve4 variety (ie not only do you have to solve for the key and provide a written step-by-step solution, but you also have to solve for the quotient and the remainder).

Additionally, the puzzle difficulty has been increased to 'hard', which should provide more of a challenge than the 'medium'-rated puzzles you've had prior.

Be sure to submit the appropriately-named and formatted files persuant to stated pctX project specifications (especially where a solve4-category puzzle is concerned).

SUBMISSION

The DEADLINE FOR SUBMISSION of this EoCE is 11:59:59pm EDT (that's 23:59:59 in 24-hour time) Tuesday, December 15th, 2026. This is the ultimate deadline for any and all coursework. There is no "late", only "too late". Don't be that person, not with this.

I would highly recommend not waiting until the last moment (or even the last week) to start on this. It has been released weeks in advance, with the intention that you chip away at it a little bit at a time, over the course of weeks.

As with the projects and other deliverables this semester, you can submit early (and worthwhile, early submissions or extra work can receive up to 7 bonus points (applicable to the EoCE grading component)), and also submit as many times as you desire. Note that when you submit, that resets the timestamp from which I will evaluate any early submission bonus points or on-time eligibility.

Eligibility of any received bonus points on the EoCE are ultimately up to my decision: if you have genuinely put forth just and honest effort that is worthy of this undertaking, you will likely receive any eligible bonus points as described. If you are more calculating and avoiding of work in your EoCE efforts, I reserve the right not to grant any bonus points.

Also, if I notice any cases of rule violations (people overhelping each other instead of letting each individual complete the EoCE on their own accord and ability), you risk forfeiting any/all bonus points or even any credit for the section(s) that you violated the rules on.

Additionally:

Solutions not abiding by spirit of project will be subject to a 50% overall deduction
Solutions not utilizing descriptive why and how comments will be subject to a 50% overall deduction
Solutions not utilizing indentation to promote scope and clarity will be subject to a 50% overall deduction
Solutions not organized and easy to read are subject to a 50% overall deduction

Good luck!