Skip to content

Releases: mountaineerbr/shellDatediff

Stable Release (v0.25)

16 Nov 23:03
Compare
Choose a tag to compare

This release sets the shebang to Bash.


Better handling of user input, bug fixes.

Fix: Inconsistent handling of base-10 arithmetic with negative and leading zeroes user input. #1

Fixes and improvements when handling user input with leading zeroes, and negative years.

Much improved handling of user dates that are in UNIX format, such as "@009000", and even "@-09000". This improves how our shell code process the UNIX dates with shell built-ins. But this update should also improve working with the C-code date wrappers when processing the user input format to ISO.

Fail gracefully when C-code date exits with error when processing user input out of their range of calculation, and fallback to the shell-built-in-only calculation code.

Fix a bug in friday-13th fun. Bash exported the modified $IFS to subshells and that was interfering with a variable expansion in the get_timef() function, so we just reset $IFS before calling the get_timef() function (bash-only).

Reduce the use of some Ksh globs, (and bash extended globbing). This may improve these small operations a little in performance.

Add Bold Colouring to some of the main function output headers (only when stdout is free).

Remove the debugf() fun from the main script and move it to the /tests directory. Probably, few people would need or know to use this piece of code other than me.


Making the code to process the user input as a best-effort basis instead of adhering to trusting absolute format correctness in user input (or rejecting it!) will make the script run slower. It will be slower from about 8% (bash) to ~38% (ksh), but this is the best code compromise.

Zsh creator writes in his Zsh guide that being a little lax about user input is a godo thing, and it is... But when we are working with three different shells, it is true to me now that if your priority is speed, one day a compromise of speed vs compatibility will have to be made nonetheless.. Even though we tried using the most basic and old shell code constructs, it does not mean some subtleties will not show up in performance when we get at it..

So, yeah. Any bigger project would have it better to stick to one modern shell only, so improvements for that shell accent can be figured out without speed compromises in other parts / interfaces of the project.. Also, that makes life much easier to fix bugs!

However, with datediff.sh script, if I would not make these code changes, then we would be having a shortcut from the standard ISO-8601 and UNIX standards, anyway.. SO it is not just a question of speed, but rather trying to reach official standards.


This fixes GitHub Issue #1.

Stable Release (v0.24.4)

13 Oct 20:59
Compare
Choose a tag to compare

Escape hyphens in roff character macros to ensure consistent rendering across groff versions.

Much improved and updated help and man documentation.

This release sets the shebang to Bash.

Since v0.24:

Correctly set the correction factor of the moon phase function to "-1892" from the input year. This has to do with C practices, as C libraries commonly use year -1900. However, after extensive testing of this correction factor, it was empirically found that "-1892" works the best for this function!

Fixes errors when input month was such as "08" (which is base 10, not octal), and also improves Bash and Zsh speed on the moon phase function by almost 5x.

Improved lunar phase function.

Stable Release (v0.24.3)

07 Oct 00:47
Compare
Choose a tag to compare

New stable release.

Improved and updated help and man documentation.

This release sets the shebang to Bash.

Since v0.24:

Correctly set the correction factor of the moon phase function to "-1892" from the input year. This has to do with C practices, as C libraries commonly use year -1900. However, after extensive testing of this correction factor, it was empirically found that "-1892" works the best for this function!

Fixes errors when input month was such as "08" (which is base 10, not octal), and also improves Bash and Zsh speed on the moon phase function by almost 5x.

Improved lunar phase function.

Stable Release (v0.24.2)

06 Oct 16:35
Compare
Choose a tag to compare

New stable release, improved lunar phase function.

This release sets the shebang to Bash.

Updated docs.

Since v0.24:

Correctly set the correction factor of the moon phase function to "-1892" from the input year. This has to do with C practices, as C libraries commonly use year -1900. However, after extensive testing of this correction factor, it was empirically found that "-1892" works the best for this function!

Fixes errors when input month was such as "08" (which is base 10, not octal), and also improves Bash and Zsh speed on the moon phase function by almost 5x.

Stable Release (v0.24.1)

05 Oct 18:58
Compare
Choose a tag to compare

New stable release, improved lunar phase function.

It fixes errors when input month was such as "08" (which is base 10), and also improves Bash and Zsh speed on this function by almost 5x.

This release sets the shebang to Bash.

Stable Release (v0.24)

03 Oct 23:48
Compare
Choose a tag to compare

Fix regression bug introduced in the previous minor release related to the lunar phase function correction factor $CFACTOR. It is now set correctly to "-1892" when $CFACTOR is unset / null!

This release sets the shebang to Bash.

Updated Docs.

Stable Release (v0.23.5)

29 Mar 14:23
Compare
Choose a tag to compare

New release with LICENSE and MAN PAGE.

The script itself has got the help page updated and some code comments removed.

First Stable Release ( v0.23.4)

21 Mar 19:04
Compare
Choose a tag to compare

This release comes after about 3 years in the development stage, and after some discussions on USENET comp.unix.shell last year, which helped improve the script.