Hi, I'm attempting to work on this issue and have linked a draft PR.

I have added the --zero option and implemented the nul/newline by changing the instances of println! to print!, then adding an "\0" or "\n" based on the existence of the flag. Is such an approach acceptable?

I'm currently trying to figure out the 2nd use of the flag, which is "and disable file name escaping". Any guidance on this would be much appreciated!

@orangeng I did some digging and if you look at the output_file function in digest.c, you'll see where the -z flag is also used to control whether "problematic characters" in the filename are escaped:

https://github.com/coreutils/coreutils/blob/v9.5/src/digest.c#L1050

They basically check if the delimiter is "\n" and if it is, then they do some special handling of the filename. Looking through the comparable code in https://github.com/uutils/coreutils/blob/main/src/uu/cksum/src/cksum.rs, I don't see anywhere where any escaping is being done, so it may be that -z is already implicitly being handled and that we need to implement escaping for when -z isn't specified.

Thanks @dchenbecker for the insights! I'm not sure about looking at the GNU coreutils source code. But at least according to the info cksum and just running the GNU coreutils version I have also noticed that -z is also used for special handling of the filenames. Specifically, the special handling happens when there is no -z flag and non-legacy algorithms (not BSD, SYSV, CRC).

Right now, the special handling of filenames isn't handled. So our behaviour is consistent with having -z (which is ignore special handling). I will add the code for special handling in cases without -z.

Right, that's what I meant. I think we don't currently do any escaping which means that we're not consistent with filename handling when -z is not specified.

@dchenbecker Please don't look at or link the GNU source code. That policy is our guarantee that uutils is original code. The documentation fair game though.

In any case, good find on that functionality!

Apologies! I only looked at digest.c, so I'll steer clear of any future contributions related to that.