From: "Daniel P. Berrange" <berrange@redhat.com>
To: "Maciej W. Rozycki" <macro@imgtec.com>
Cc: Stefan Weil <sw@weilnetz.de>,
QEMU Trivial <qemu-trivial@nongnu.org>,
QEMU Developer <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] configure: Use $(..) instead of deprecated `..`
Date: Wed, 8 Jun 2016 13:48:20 +0100 [thread overview]
Message-ID: <20160608124819.GI7760@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1606081305490.10382@tp.orcam.me.uk>
On Wed, Jun 08, 2016 at 01:16:59PM +0100, Maciej W. Rozycki wrote:
> On Mon, 16 May 2016, Stefan Weil wrote:
>
> > This fixes these warnings from shellcheck:
> >
> > ^-- SC2006: Use $(..) instead of deprecated `..`
> >
> > Signed-off-by: Stefan Weil <sw@weilnetz.de>
> > ---
> >
> > More warnings from shellcheck for configure and other files
> > will be handled by later patches.
>
> Unlike `..` the $(..) Bourne shell construct is not fully portable, some
> implementations do not recognise it. Consequently this change potentially
> breaks building QEMU on some systems, possibly in a non-obvious way, as
> there's no explicit check for the presence this feature and a graceful
> failure path included with this patch or the other one AFAICT. We may or
> may not care about those systems, but still this is a functional
> regression and therefore I think there has to be a good reason for
> introducing it.
I found that the bash wiki has a note about this
http://wiki.bash-hackers.org/scripting/obsolete
"This is the older Bourne-compatible form of the command substitution.
Both the `COMMANDS` and $(COMMANDS) syntaxes are specified by POSIX,
but the latter is _greatly_ preferred, though the former is unfortunately
still very prevalent in scripts. New-style command substitutions are
widely implemented by every modern shell (and then some). The only
reason for using backticks is for compatibility with a real Bourne
shell (like Heirloom). Backtick command substitutions require special
escaping when nested, and examples found in the wild are improperly
quoted more often than not."
> So what's the technical justification -- beyond shutting up some random
> checker tool -- for making this change? Does the benefit recognised in
> making this change outweigh the limitation introduced? How about handling
> failures properly?
Seems the main benefit of $(...) is around escaping/quoting. Since `..`
is in POSIX and widely used, support for it is never going to be deleted,
regardless of whether people decide to call it 'deprecated'. IOW, unless
QEMU hits the issue with the escaping/quoting, there's no compelling reason
to avoid `...`
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
next prev parent reply other threads:[~2016-06-08 12:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-16 13:10 [Qemu-devel] [PATCH] configure: Use $(..) instead of deprecated `..` Stefan Weil
2016-05-29 8:19 ` Michael Tokarev
2016-06-08 12:16 ` Maciej W. Rozycki
2016-06-08 12:48 ` Daniel P. Berrange [this message]
2016-06-08 13:07 ` Stefan Weil
2016-06-08 13:46 ` Maciej W. Rozycki
2016-06-08 14:05 ` Eric Blake
2016-06-08 14:38 ` Maciej W. Rozycki
2016-06-08 15:07 ` Peter Maydell
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=20160608124819.GI7760@redhat.com \
--to=berrange@redhat.com \
--cc=macro@imgtec.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
--cc=sw@weilnetz.de \
/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).