On 2020-01-02, Quentin Rameau <quinq_AT_fifth.space> wrote:
> I agree in that silently ignoring commands from the user is bad, as it
> breaks expectations.
Well, in this case ignoring them is a valid implementation, since on
POSIX there is no distinction between opening a file as text or binary
mode. So it will return the correct result with those flags.
> Though as noted in this case, those are not standardized (maybe that
> wasn't a great idea to add them in sbase instead of ubase even if they
> can be implemented in a portable manner), so anything can happen there.
There is
http://austingroupbugs.net/view.php?id=1041 which encourages
implementations to provide *some* method of checksum with high
security, but unfortunately still has no specification of what that
looks like.
> I'm not sure we should start adding those kind of half-compability
> parsing with coreutils, where do we stop?
I disagree that it is "half-compatibility", but this is a good point.
It's kind of a similar issue with tar(1), which was removed from
POSIX, but still extremely widely used. I think the best we can do is
implement the options that are commonly expected of the tools. In this
case implementing -b and -t is as simple as adding a case to a switch,
so I don't see much downside to doing so.
> Also for what it's worth:
>
> $ busybox md5sum -b md5sum.c
> md5sum: unrecognized option: b
> BusyBox v1.31.1 (2019-11-29 10:55:12 UTC) multi-call binary.
>
> Usage: md5sum [FILE]...
>
> $ busybox md5sum -t md5sum.c
> md5sum: unrecognized option: t
> BusyBox v1.31.1 (2019-11-29 10:55:12 UTC) multi-call binary.
>
> Usage: md5sum [FILE]...
Looks like with busybox the -b and -t options depend on
ENABLE_FEATURE_MD5_SHA1_SUM_CHECK, which also enables the -c flag.
$ busybox md5sum -b /dev/null
d41d8cd98f00b204e9800998ecf8427e /dev/null
Received on Thu Jan 02 2020 - 20:41:34 CET