qemu-trivial
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-trivial] [Qemu-devel] [PATCH] configure: Use $(..) instead of


From: Daniel P. Berrange
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] configure: Use $(..) instead of deprecated `..`
Date: Wed, 8 Jun 2016 13:48:20 +0100
User-agent: Mutt/1.6.0 (2016-04-01)

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 <address@hidden>
> > ---
> > 
> > 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 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]