Re: CVS commit: src/usr.bin/cksum

[Elad Efrat <elad%NetBSD.org@localhost>]

John Hawkinson wrote:

> This...doesn't really seem to address the problem as well
> as I would have liked...

This wasn't meant to solve the problem, and was removed in a commit I
just did. In fact, I added this comment before reading your comments. :)

> The man page ought to explain what the options *do*. Just because they
> are deprecated doesn't mean that a user should not be able to determine
> their functionality.

I understood what you meant the first time, but due to lack of time I
didn't add these notes to the man-page. Now that I got home, I added
these back to the man-page, noting they are deprecated and should not
be used, and that they were used to choose the hashing algorithm to be
used.

> It should say that they are deprecated, and maybe put the deprecated
> options in a seperate section (DEPRECATED?) instead of lumped in with
> the others.

I added them back with the others, at the top of the flags list.

> But you don't say *why* they are de[recated. That's important too!
> (and actually, I guess I don't know why they are deprecated? Why
> are they deprecated?).

Why they were deprecated is not relevant to the user, but for the
record, they simply do not scale well. I'm about to add SHA2 to cksum
and support its 256, 384, and 512 bit versions. What flags should be
used for these? if we go with the current logic, then -8 should be
for the 384 bit version ``because both has 8 in them''. What about the
other two? What about newer algorithms we might add?

Using a ``-a <algorithm>'' is easier to read, easier to use in scripts,
and easier to support in code and when adding new algorithms to the
system.

I've already talked about this with atatat@ who added these flags, and
on ICB where the concensus was to deprecate these flags, add the ``-a''
flag. I also don't know any other OS where these flags are used except
for NetBSD. For compatibility reasons, they were left in the code, and
after it was asked to also leave them in the documentation, I did so
as well.

> I'm confused why that is a comment, though, rather than in the
> NOTES section? Why do you want to hide this information from users
> who might legitimately want to know?

Let's put things back in proportion. All the changes I've made are
publicly available, I didn't argue with anyone about putting these
flags back in the documentation -- and for the whole time they were
left supported in the code.

I may be wrong (because there's no way to actually check it ;) but
IMHO the number of users that may be ``hit'' due to these flags being
*completely* removed can be counted on one hand... not to mention the
number of users who will be reading scripts using cksum with these
flags, not understanding what they mean, and running a -current system.

We need to be consistent. If we bring these flags back in, then we also
need to come up with per-algorithm flags for new additions as well.
Once these run out, we might also consider using long options for cksum.
OR, we can be reasonable, and use what seems to be the most logical
solution of allowing the user to specify what algorithm he wants to use.
That way I believe we also save man-page readin for some people, and
gain compatibility with OpenBSD.

-e.

-- 
Elad Efrat
PGP Key ID: 0x666EB914