On 2020-01-02, Quentin Rameau <quinq@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