Re: [PATCH 07/27] qemu-img: check: refresh options/--help

[Kevin Wolf <kwolf@redhat.com>]

Am 31.05.2025 um 18:51 hat Michael Tokarev geschrieben:
> On 13.05.2025 18:54, Kevin Wolf wrote:
> > Am 27.09.2024 um 08:11 hat Michael Tokarev geschrieben:
> > > Add missing long options and --help output.
> ...
> > > +"  --image-opts\n"
> > > +"     indicates that FILENAME is a complete image specification\n"
> > > +"     instead of a file name (incompatible with --format)\n"
> > 
> > The man page has:
> > 
> >    Indicates that the source *FILENAME* parameter is to be interpreted as a
> >    full option string, not a plain filename. This parameter is mutually
> >    exclusive with the *-f* parameter.
> > 
> > A possible adaptation for qemu-img check specially:
> > 
> >    indicates that FILENAME is a full option string, not a plain filename
> >    (incompatible with --format)
> 
> What I ended up now is:
> 
>   --image-opts
>      treat FILE as an option string (key=value,..), not a file name
>      (incompatible with -f|--format)

That's better, I like it.

I'm not sure if we really need to have both short and long name for
incomatible options, but I don't mind either way as long as we're
consistent with it.

> Note I used short "FILE" everywhere, while in the manpage we see
> longer FILENAME - my plan is to get the manpage to use the same
> FILE too, in the next step (I can probably do it together with
> each individual commit in this series too).
> 
> Maybe it's better to use IMAGE instead of FILE, because:
> 
>   FILE
>      name of the image file, or an option string (key=value,..)
>      with --image-opts, to operate on
> 
> (this is another common idiom I used in all the changes).

I think FILE is clear enough, but I wouldn't object to IMAGE either.

> > > +"  --object OBJDEF\n"
> > > +"     QEMU user-creatable object (eg encryption key)\n"
> > 
> > "e.g."
> 
> it is also different from the manpage (where OBJECTDEF is used).
> I ended up with just:
> 
>   --object OBJDEF
>      defines QEMU user-creatable object
> 
> Since --object can be used with any command, maybe it's a good
> idea to have it in common options string, before a subcommand.

That is an interesting idea. But wouldn't we need to keep the existing
code anyway for compatibility? I don't think we have code so far for
options that can be used both before and after the subcommand name.

Kevin