Improvements to "Cron Job Schedule" validation & translation.#142
Improvements to "Cron Job Schedule" validation & translation.#142ExtremeFiretop merged 2 commits intoExtremeFiretop:devfrom
Conversation
- Added a validator for the "Cron Job Schedule" user input to try to prevent users from setting an invalid check schedule and then wondering why it didn't work. It's not an exhaustive validation but it flags the most common user errors.
- Improve translation of "Cron Job Schedule" string to English.
Now it handles abbreviated short names for month ("Jan", "Feb", etc.) and day of the week ("Sun", "Mon", etc.).
|
OK, it's all yours now. Once you're happy that everything is working well and no issues are found, you can merge into the "main" branch and issue a new release. |
Starting my review now :) |
I'll be around checking for any problems reported. I was just informed that dinner will be ready in about 15 minutes so I'll take a break then. |
| ## Modified by Martinski W. [2024-Feb-22] ## | ||
| ##----------------------------------------## | ||
| readonly FW_Update_CRON_DefaultSchedule="0 0 * * 0" | ||
| readonly FW_Update_CRON_DefaultSchedule="0 0 * * Sun" |
There was a problem hiding this comment.
Approving changes to default values
|
|
||
| # Special handling for "month" to map short abbreviations to long full names # | ||
| month_text="$(echo "$month_text" | tr [A-Z] [a-z])" | ||
| month_map1="jan:January feb:February mar:March apr:April may:May jun:June jul:July aug:August sep:September oct:October nov:November dec:December" |
There was a problem hiding this comment.
Ahhh, yes I see, this is smart, having a map1 and map2, one for each depending what is used. (short form or number)
| then | ||
| # Special handling for "day of the week" to map short abbreviations to long full names # | ||
| day_of_week_text="$(echo "$day_of_week_text" | tr [A-Z] [a-z])" | ||
| dow_map1="sun:Sunday mon:Monday tue:Tuesday wed:Wednesday thu:Thursday fri:Friday sat:Saturday" |
There was a problem hiding this comment.
Again, this is smart, I see what you mean by exhaustive lol
| readonly FW_Update_CRON_DefaultSchedule="0 0 * * Sun" | ||
|
|
||
| readonly CRON_MINS_RegEx="([*0-9]|[1-5][0-9])([\/,-]([0-9]|[1-5][0-9]))*" | ||
| readonly CRON_HOUR_RegEx="([*0-9]|1[0-9]|2[0-3])([\/,-]([0-9]|1[0-9]|2[0-3]))*" |
There was a problem hiding this comment.
Approved the newly added regular expressions
| ##-------------------------------------## | ||
| ## Added by Martinski W. [2024-Feb-22] ## | ||
| ##-------------------------------------## | ||
| _ValidateCronJobSchedule_() |
There was a problem hiding this comment.
I see, so basically every input now is validated against these new regular expressions.
This addition really enhances the robustness of the cron section of the script by preventing incorrect cron schedule entries :) I like it!
|
|
||
| readonly CRON_DAYofWEEK_NAMES="(Sun|Mon|Tue|Wed|Thu|Fri|Sat)" | ||
| readonly CRON_DAYofWEEK_RegEx="$CRON_DAYofWEEK_NAMES([\/,-]$CRON_DAYofWEEK_NAMES)*|[0-6*]([\/,-][0-6])*" | ||
| readonly CRON_DAYofWEEK_RegEx="$CRON_DAYofWEEK_NAMES([\/,-]$CRON_DAYofWEEK_NAMES)*|[*0-6]([\/,-][0-6])*" |
There was a problem hiding this comment.
Approved the newly added regular expressions
|
Okay all changes understood and approved so far!. Running some tests now against the changes! |
| printf "${REDct}INVALID cron schedule string [$1]. Incorrect number of parameters.${NOct}\n" | ||
| return 1 | ||
| fi | ||
| cronSchedsStr="$(echo "$1" | awk -F ' ' '{print $1}')" |
There was a problem hiding this comment.
exhaustive validation alright lol!
There was a problem hiding this comment.
exhaustive validation alright lol!
Well, it's not quite an exhaustive check & validation; it's more like a syntax parser validator so it will flag the most common user errors WRT syntax, but a user can still set a "syntactically correct" schedule that it will not work like:
10 3 31 2 0
10 3 31 Feb Sun
The above entries are obviously wrong and will never actually work. Adding checks & validation for semantic errors is much more complicated and would require dozens of small functions for each possible case. Not something I'm willing to spend time on just for this one user input. My take is that users should make some effort to learn how to set a semantically valid cron schedule and take responsibility for making such errors.
|
So far all the tests pass perfect! Here is a complete list of valid crons I've tested to try and break the validation without success: A small list of some invalid crons below I tried to use to trick the validation without success: |
Excellent!! I went through a similar long list of valid & invalid entries to verify functionality and my final test results went perfectly well. Thank you for testing & verifying the code. |
|
OK, I'm being summoned by a "higher power." :>) Be back in 30 or so... |
Enjoy dinner! Ready to release when your back! |
Added a validator for the "Cron Job Schedule" user input to try to prevent users from setting an invalid check schedule and then wondering why it didn't work. It's not an exhaustive validation but it flags the most common user errors.
Improve translation of the "Cron Job Schedule" string to English.
Now it handles abbreviated short names for "month" values ("Jan", "Feb", "Mar", etc.) and for "day of the week" values ("Sun", "Mon", "Tue", etc.) and outputs the full names.