Adding the extension to the executable is non-standard,
Indeed Hroptatyr's 'C-code datediff' already exists in community as 'dateutils'. It is not desirable to install the datediff.sh script as 'datediff' to avoid such instance of conflict.. However, what binary name would be cool to install the script with?
However(!), datediff is already an existing tool in community/datediff
C-code datediff only accepts ISO-8601 dates, whereas the datediff.sh script warps `GNU date', if available (which usually is) to process input dates to ISO-8601 before calendrical calculations are performed, and it is verbose by defaults so you get a lot of info about any two dates instantly after typing them.
md5 is broken and should not be used, sha256 or similar would be advised.
Will use other checksum algos... Will switch to sha1. Thanks! On 22/03/2023 08:16, Martin Rys wrote:
Would installing the script as `datediff.sh' to /usr/bin be standard? I believe /usr/bin/datediff would. Adding the extension to the executable is non-standard, lots of binaries are plaintext, but they do not carry their extension. Imagine you rewrite your tool to use python instead, now you and everyone else who relies on the tool has to deal with the breaking change, whereas if the extension is never present, this isn't a problem. It also makes it nicer to be typed out in a terminal without having to mash TAB.
However(!), datediff is already an existing tool in community/dateutils, which seems to have a similar use case as your tool does.
Suggestions are appreciated md5 is broken and should not be used, sha256 or similar would be advised.