Re: Add support for cksum --algorithm [sm3]

[Pádraig Brady]

On 09/09/2021 14:23, Michael Stone wrote:
> On Thu, Sep 09, 2021 at 01:20:56PM +0100, Pádraig Brady wrote:
> > On 09/09/2021 00:39, Michael Stone wrote:
> > > On Tue, Sep 07, 2021 at 04:45:23PM +0100, Pádraig Brady wrote:
> > > > This patch set refactors all digest implementations
> > > > to their own modules, all interfaced through digest.c.
> > > > All file operations and diagnostics are done in digest.c.
> > > > All digests are made available through `cksum -a`.
> > > > Also we add support for SM3 through `cksum -a sm3` only.
> > >
> > > Might be nice if there was something like "-a list-available" to see
> > > what algorithms are available without parsing the --help output.
> >
> > That's pretty much supported already in the argmatch functionality.
> > I.e. if you use `cksum -a list-available`, the list of possibilities are 
> > printed.
> > I generally use that feature like:
> >
> > $ cksum --algo=
>
> I don't think that's all that much better than just parsing --help --
> there's still a lot of formatting and unnecessary verbiage to weed out.

Well it's a lot more structured than --help in fairness

> If that is the preferred approach, though, then document that as the
> preferred/stable way to programatically detect the available algorithms.

Fair point.

It is fairly easy to programatically get the args currently.
For example:

  long_opt_args() {
    LC_ALL=C "$1" "$2"=_list_available_ 2>&1 |
     sed -n "s/^  - '\(.*\)'/\1/p"
  }

  $ long_opt_args tee --output-error
  $ long_opt_args ls --quoting-style

I see my Fedora distro auto installs shell completions from:
https://github.com/scop/bash-completion
So it seems useful to add the above functionality
for the coreutils and similar commands at least.

> (In general I think one of the problems with the way the unix command
> line has evolved is that it's generally easier to just stick with
> whatever functionality existed 20 years ago than it is to write shell
> scripts that can discover what new functionality is present and fall
> back gracefully. Designing a new command that's intended to be
> extensible without building in a way for consumers to easily find out
> what extensions are present seems like a bad idea.)

Right, for graceful fallback it's tricky:
`{ cksum -a md5 || md5sum; } | ...` doesn't generally work,
as the failure could be due to input issues etc. rather than option support.

Following on from the above example, one might:

  prog=$(long_opt_args cksum --algo | grep -qx md5 && echo 'cksum -a md5' || 
echo 'md5sum')

Not very elegant, but is fairly general.
If one updated getopt/argmatch to support something like:

  prog=$(cksum --?algo=md5 && echo 'cksum -a md5' || echo 'md5sum')

That would be a bit more elegant, but less widely supported.

Anyway all this is a general issue,
that cksum shouldn't be considering in isolation I think.

cheers,
Pádraig