qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Claudio Fontana" <cfontana@suse.de>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Christian Schoenebeck" <qemu_oss@crudebyte.com>,
	"Akihiko Odaki" <akihiko.odaki@gmail.com>,
	qemu-devel@nongnu.org,
	"Richard Henderson" <richard.henderson@linaro.org>
Subject: Re: [PATCH] audio: add help option (?) for -audiodev
Date: Thu, 08 Sep 2022 07:20:16 +0200	[thread overview]
Message-ID: <87y1uusar3.fsf@pond.sub.org> (raw)
In-Reply-To: <Yxi3MOT/s8nn45zp@redhat.com> ("Daniel P. Berrangé"'s message of "Wed, 7 Sep 2022 16:22:24 +0100")

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Wed, Sep 07, 2022 at 05:06:36PM +0200, Markus Armbruster wrote:
>> Claudio Fontana <cfontana@suse.de> writes:
>> 
>> > add a simple help option for -audiodev, so users can do
>> >
>> > qemu -audiodev ?
>> 
>> The preferred form is actually '-audiodev help'.  The other one is
>> deprecated.  Recommend to stay away from it even in commit messages.
>
> We introduced 'help' many many years ago, but don't thing we
> ever formally deprecated '?'.

is_help_option()'s function comment says "'?' is deprecated".  Goes back
to

commit c8057f951d64de93bfd01569c0a725baa9f94372
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Thu Aug 2 13:45:54 2012 +0100

    Support 'help' as a synonym for '?' in command line options
    
    For command line options which permit '?' meaning 'please list the
    permitted values', add support for 'help' as a synonym, by abstracting
    the check out into a helper function.
    
    This change means that in some cases where we were being lazy in
    our string parsing, "?junk" will now be rejected as an invalid option
    rather than being (undocumentedly) treated the same way as "?".
    
    Update the documentation to use 'help' rather than '?', since '?'
    is a shell metacharacter and thus prone to fail confusingly if there
    is a single character filename in the current working directory and
    the '?' has not been escaped. It's therefore better to steer users
    towards 'help', though '?' is retained for backwards compatibility.
    
    We do not, however, update the output of the system emulator's -help
    (or any documentation autogenerated from the qemu-options.hx which
    is the source of the -help text) because libvirt parses our -help
    output and will break. At a later date when QEMU provides a better
    interface so libvirt can avoid having to do this, we can update the
    -help text too.
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

The more formal deprecation process we use today didn't exist in 2012.
Looks like we simply de-documented '?'.

Note that output of -help has been updated since.

>                                Should we do so and aim to
> remove it, or are we happy to keep '?' forever, despite it
> tripping up shell filename expansion with single char filenames.

I'm not sure a belated formal notice of deprecation would be useful.

Emitting a warning might be.  Would have to be done at roughly 20 call
sites, I guess.

I'm cool with removing a feature that has been undocumented for a
decade.  However, experience tells us that every feature on the chopping
block will find a champion, and I believe this one is still around
simply because it's not worth a fight.

[...]



  parent reply	other threads:[~2022-09-08  5:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-07 14:23 [PATCH] audio: add help option (?) for -audiodev Claudio Fontana
2022-09-07 15:06 ` Markus Armbruster
2022-09-07 15:22   ` Daniel P. Berrangé
2022-09-07 16:07     ` BALATON Zoltan
2022-09-08  5:20     ` Markus Armbruster [this message]
2022-09-07 15:56   ` Claudio Fontana

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y1uusar3.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=akihiko.odaki@gmail.com \
    --cc=berrange@redhat.com \
    --cc=cfontana@suse.de \
    --cc=f4bug@amsat.org \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu_oss@crudebyte.com \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).