| Age | Commit message (Collapse) | Author |
|---|
|
The datediff.sh script wraps c-code date when available to make it easier for the user to input dates in various extra formats.
In this release, improve the code to select the right c-code date implementation amongst GNU, BSD, old AST, Busybox, and ToyBox.
Also, improve some user warning messages.
|
|
The `-t` option now **exclusively** produces a table-formatted output for single-unit time intervals.
The previously required `-v` option to display **only** the table is no longer needed in conjunction with `-t`.
|
|
|
|
|
|
Fix: Inconsistent handling of base-10 arithmetic with negative and leading zeroes user input. https://github.com/mountaineerbr/shellDatediff/issues/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.
|
|
T.P.RoffChar: escape - as \-. The groff_man (7) man page indicates that - characters will be treated as typographic hyphens and are not appropriate for cases where the output should be copy-pasteable as an ASCII hyphen-minus character. (E.g. in command line options.) However, until a recent update groff man did not actually do this; it treated - and \- the same. With the new update (1.23.0) the two are distinguished (see https://lwn.net/Articles/947941/ for background), so now it is important that pandoc escape -.
|
|
This update improves documentation (help and man pages), and also the repo README.md file with more examples and better explanantion of some function.
|
|
|
|
|
|
The man page source had different markdown than was expected.
|
|
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.
|
|
It fixes errors when input month is such as "08" (is base 10), and also improves Bash and Zsh speed on this function by 5x.
|
|
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_!
Updated Docs.
NOTE: THE SOURCE IS NOW AVAILABLE AGAIN!
|
|
|
|
Update documentation (help, man and readme pages).
In the script lunar fase function, $CFACTOR is not set automatically to "-1892" if it is null (only when $CFACTOR is unset).
|
|
|
|
|
|
|
|
|
|
|