Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

["J.A. Bezemer" <costar@wormhole.robuust.nl>]

On Fri, 9 Feb 2007, Jari Aalto wrote:

> FOREWORD
> 
>     I have seen following construct to be used in shell-context
>     (makefiles, sh-scripts, Perl):
> 
>       `cmd` [1]
> 
>     However, the POSIX standard and SUSv[23] declares alternative way of
>     accomplishing the same with in *sh context:
> 
>       $(cmd) [2]

[..]
>     All Debian *sh compatible shells support $() and are thus POSIX/SUS
>     compliant in this respect. 

[..]
> The Single UNIX Specification, Version 2 (SUSv2):
> "Shell Command Language"
> <http://www.opengroup.org/onlinepubs/007908799/xcu/chap2.html>
> 
>     ...The input characters within the quoted string that are
>     also enclosed between "$(" and the matching ")" will not
>     be affected by the double-quotes, but rather define that
>     command whose output replaces the $(...)

Your mail makes it sound like $( ) is the only command substitution
allowed by POSIX/SUSv[23]. It is not. Let me quote the _really_ relevant
section of SUSv2,
http://www.opengroup.org/onlinepubs/007908799/xcu/chap2.html#tag_001_006_003
and SUSv3 = POSIX (IEEE1003.1, 2004 Edition),
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03

    Command substitution allows the output of a command to be substituted
    in place of the command name itself. Command substitution shall occur
    when the command is enclosed as follows:

        $(command)

    or (backquoted version):

        `command`


Further, you didn't yet mention the only disadvantage of backquotes that I
personally find important enough to consider, namely that (multi-level)
nesting quickly gets horrible. So I personally tend to use $( ) only when
nesting.

And exactly that is also the only reason mentioned in the Rationale volume
of SUSv3/POSIX,
http://www.opengroup.org/onlinepubs/009695399/xrat/xcu_chap02.html#tag_02_02_06_03

    ... Because of these inconsistent behaviors, the backquoted variety of
    command substitution is not recommended for new applications __that
    nest command substitutions or attempt to embed complex scripts__.

(my underlining.)


Best regards,

  Anne Bezemer