Have backticks (i.e. `cmd`) in *sh shells been deprecated?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
108
down vote

favorite
21












I've seen this comment many times on Unix & Linux as well as on other sites that use the phrasing "backticks have been deprecated", with respect to shells such as Bash & Zsh.



Is this statement true or false?










share|improve this question























  • See Why didn't back quotes in a shell script help me cd to a directory for an example of why $(...) notation is easier to use than nested back-quotes.
    – Jonathan Leffler
    Apr 29 '14 at 0:52











  • punch line here
    – Trevor Boyd Smith
    Aug 17 '16 at 12:27










  • At least one Unix, AIX, has documented that backticks are obsolete. "Although the backquote syntax is accepted by ksh, it is considered obsolete by the X/Open Portability Guide Issue 4 and POSIX standards. These standards recommend that portable applications use the $(command) syntax." ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.osdevice/…
    – Christopher
    4 mins ago














up vote
108
down vote

favorite
21












I've seen this comment many times on Unix & Linux as well as on other sites that use the phrasing "backticks have been deprecated", with respect to shells such as Bash & Zsh.



Is this statement true or false?










share|improve this question























  • See Why didn't back quotes in a shell script help me cd to a directory for an example of why $(...) notation is easier to use than nested back-quotes.
    – Jonathan Leffler
    Apr 29 '14 at 0:52











  • punch line here
    – Trevor Boyd Smith
    Aug 17 '16 at 12:27










  • At least one Unix, AIX, has documented that backticks are obsolete. "Although the backquote syntax is accepted by ksh, it is considered obsolete by the X/Open Portability Guide Issue 4 and POSIX standards. These standards recommend that portable applications use the $(command) syntax." ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.osdevice/…
    – Christopher
    4 mins ago












up vote
108
down vote

favorite
21









up vote
108
down vote

favorite
21






21





I've seen this comment many times on Unix & Linux as well as on other sites that use the phrasing "backticks have been deprecated", with respect to shells such as Bash & Zsh.



Is this statement true or false?










share|improve this question















I've seen this comment many times on Unix & Linux as well as on other sites that use the phrasing "backticks have been deprecated", with respect to shells such as Bash & Zsh.



Is this statement true or false?







bash shell-script shell scripting zsh






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jul 10 at 7:31

























asked Apr 28 '14 at 14:57









slm♦

242k66501669




242k66501669











  • See Why didn't back quotes in a shell script help me cd to a directory for an example of why $(...) notation is easier to use than nested back-quotes.
    – Jonathan Leffler
    Apr 29 '14 at 0:52











  • punch line here
    – Trevor Boyd Smith
    Aug 17 '16 at 12:27










  • At least one Unix, AIX, has documented that backticks are obsolete. "Although the backquote syntax is accepted by ksh, it is considered obsolete by the X/Open Portability Guide Issue 4 and POSIX standards. These standards recommend that portable applications use the $(command) syntax." ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.osdevice/…
    – Christopher
    4 mins ago
















  • See Why didn't back quotes in a shell script help me cd to a directory for an example of why $(...) notation is easier to use than nested back-quotes.
    – Jonathan Leffler
    Apr 29 '14 at 0:52











  • punch line here
    – Trevor Boyd Smith
    Aug 17 '16 at 12:27










  • At least one Unix, AIX, has documented that backticks are obsolete. "Although the backquote syntax is accepted by ksh, it is considered obsolete by the X/Open Portability Guide Issue 4 and POSIX standards. These standards recommend that portable applications use the $(command) syntax." ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.osdevice/…
    – Christopher
    4 mins ago















See Why didn't back quotes in a shell script help me cd to a directory for an example of why $(...) notation is easier to use than nested back-quotes.
– Jonathan Leffler
Apr 29 '14 at 0:52





See Why didn't back quotes in a shell script help me cd to a directory for an example of why $(...) notation is easier to use than nested back-quotes.
– Jonathan Leffler
Apr 29 '14 at 0:52













punch line here
– Trevor Boyd Smith
Aug 17 '16 at 12:27




punch line here
– Trevor Boyd Smith
Aug 17 '16 at 12:27












At least one Unix, AIX, has documented that backticks are obsolete. "Although the backquote syntax is accepted by ksh, it is considered obsolete by the X/Open Portability Guide Issue 4 and POSIX standards. These standards recommend that portable applications use the $(command) syntax." ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.osdevice/…
– Christopher
4 mins ago




At least one Unix, AIX, has documented that backticks are obsolete. "Although the backquote syntax is accepted by ksh, it is considered obsolete by the X/Open Portability Guide Issue 4 and POSIX standards. These standards recommend that portable applications use the $(command) syntax." ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.osdevice/…
– Christopher
4 mins ago










3 Answers
3






active

oldest

votes

















up vote
115
down vote



accepted










There are two different meanings of "deprecated."




be deprecated: (chiefly of a software feature) be usable but regarded as obsolete and best avoided, typically due to having been superseded.



—New Oxford American Dictionary




By this definition backticks are deprecated.




Deprecated status may also indicate the feature will be removed in the future.



—Wikipedia




By this definition backticks are not deprecated.



Still supported:



Citing the Open Group Specification on Shell Command Languages,
specifically section "2.6.3 Command Substitution," it can be seen that both forms of command substitution, backticks (`..cmd..`) or dollar parens ($(..cmd..)) are still supported insofar as the specification goes.



excerpt




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`


The shell shall expand the command substitution by executing command in a
subshell environment (see Shell Execution Environment) and replacing the
command substitution (the text of command plus the enclosing $() or
backquotes) with the standard output of the command, removing sequences of one
or more <newline> characters at the end of the substitution. Embedded <newline> characters before the end of the output shall not be removed; however,
they may be treated as field delimiters and eliminated during field splitting,
depending on the value of IFS and quoting that is in effect. If the output
contains any null bytes, the behavior is unspecified.



Within the backquoted style of command substitution, <backslash> shall retain
its literal meaning, except when followed by: '$', '`', or <backslash>. The
search for the matching backquote shall be satisfied by the first unquoted
non-escaped backquote; during this search, if a non-escaped backquote is
encountered within a shell comment, a here-document, an embedded command
substitution of the $(command) form, or a quoted string, undefined results
occur. A single-quoted or double-quoted string that begins, but does not end,
within the "`...`" sequence produces undefined results.



With the $(command) form, all characters following the open parenthesis to
the matching closing parenthesis constitute the command. Any valid shell
script can be used for command, except a script consisting solely of
re-directions which produces unspecified results.




So then why does everyone say that backticks have been deprecated?



Because most of the use cases should be making use of the dollar parens form instead of backticks. (Deprecated in the first sense above.) Many of the most reputable sites (including U&L) often state this as well, throughout, so it's sound advice. This advice should not be confused with some non-existent plan to remove support for backticks from shells.



  • BashFAQ #082 - Why is $(...) preferred over `...` (backticks)?

excerpt




`...` is the legacy syntax required by only the very oldest of
non-POSIX-compatible bourne-shells. There are several reasons to always
prefer the $(...) syntax:



...




  • Bash Hackers Wiki - Obsolete and deprecated syntax

excerpt




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. See:
Why is $(...) preferred over `...` (backticks)?.




  • POSIX standard rationale

excerpt




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.




NOTE: This third excerpt (above) goes on to show several situations where backticks simply won't work, but the newer dollar parens method does, beginning with the following paragraph:




Additionally, the backquoted syntax has historical restrictions on the contents of the embedded command. While the newer "$()" form can process any kind of valid embedded script, the backquoted form cannot handle some valid scripts that include backquotes.




If you continue reading that section the failures are highlighted showing how they would fail using backticks, but do work using the newer dollar parens notation.



Conclusions



So it's preferable that you use dollar parens instead of backticks but you aren't actually using something that's been technically "deprecated" as in "this will stop working entirely at some planned point."



After reading all this you should have the take away that you're strongly encouraged to use dollar parens unless you specifically require compatibility with a real original non-POSIX Bourne shell.






share|improve this answer


















  • 25




    By most of the meanings of deprecated, I (and you) would say that backticks are deprecated. It's mostly a terminology question.
    – Stéphane Chazelas
    Apr 28 '14 at 15:54






  • 4




    @StephaneChazelas - Agreed! I will continue to tell ppl that they're deprecated but backticks have not been officially "deprecated" in the sense that they're going to be actively removed from the code base of any shell in the near future. At least none that I'm aware of.
    – slm♦
    Apr 28 '14 at 16:00






  • 3




    My interpretation is that backquotes are supported purely because they are too entrenched in existing code to formally deprecate. I have never heard an argument for continuing to use them in new code.
    – chepner
    Apr 28 '14 at 16:08






  • 2




    @chepner - neither have I, but if you come across them there may be a very good reason that someone who understands the implications might have chosen them over dollar parens. But odds are they were likely used b/c the user just didn't understand there's an alternative in dollar parens.
    – slm♦
    Apr 28 '14 at 16:14






  • 3




    @slm Yeah, I guess you did get it - I got pulled away and didn't notice. There's almost no reason to use these things, except that it can be just a little cleaner when layering subshells so $( cmd `cmd`) is just a little less messy than $( cmd $(cmd)) - it's easier to read. I've just always considered a deprecated feature in software to be one officially marked for removal by upstream - and I've never heard of anything like that. I don't care - have no love for the grave.
    – mikeserv
    Apr 28 '14 at 18:27


















up vote
12
down vote













It's not deprecated, but the backticks (`...`) is the legacy syntax required by only the very oldest of non-POSIX-compatible bourne-shells and $(...) is POSIX and more preferred for several reasons:




  • Backslashes () inside backticks are handled in a non-obvious manner:



    $ echo "`echo \a`" "$(echo \a)"
    a a
    $ echo "`echo \\a`" "$(echo \\a)"
    a \a
    # Note that this is true for *single quotes* too!
    $ foo=`echo '\'`; bar=$(echo '\'); echo "foo is $foo, bar is $bar"
    foo is , bar is \



  • Nested quoting inside $() is far more convenient:



    echo "x is $(sed ... <<<"$y")"


    instead of:



    echo "x is `sed ... <<<"$y"`"


    or writing something like:



    IPs_inna_string=`awk "/`cat /etc/myname`/"'print $1' /etc/hosts`


    because $() uses an entirely new context for quoting



    which is not portable as Bourne and Korn shells would require these backslashes, while Bash and dash don't.




  • Syntax for nesting command substitutions is easier:



    x=$(grep "$(dirname "$path")" file)


    than:



    x=`grep "`dirname "$path"`" file`


    because $() enforces an entirely new context for quoting, so each command substitution is protected and can be treated on its own without special concern over quoting and escaping. When using backticks, it gets uglier and uglier after two and above levels.



    Few more examples:



    echo `echo `ls`` # INCORRECT
    echo `echo `ls`` # CORRECT
    echo $(echo $(ls)) # CORRECT



  • It solves a problem of inconsistent behavior when using backquotes:




    • echo '$x' outputs $x


    • echo `echo '$x'` outputs $x


    • echo $(echo '$x') outputs $x



  • Backticks syntax has historical restrictions on the contents of the embedded command and cannot handle some valid scripts that include backquotes, while the newer $() form can process any kind of valid embedded script.



    For example, these otherwise valid embedded scripts do not work in the left column, but do work on the rightIEEE:



    echo ` echo $(
    cat <<eof cat <<eof
    a here-doc with ` a here-doc with )
    eof eof
    ` )


    echo ` echo $(
    echo abc # a comment with ` echo abc # a comment with )
    ` )


    echo ` echo $(
    echo '`' echo ')'
    ` )


Therefore the syntax for $-prefixed command substitution should be the preferred method, because it is visually clear with clean syntax (improves human and machine readability), it is nestable and intuitive, its inner parsing is separate, and it is also more consistent (with all other expansions that are parsed from within double-quotes) where backticks are the only exception and ` character is easily camouflaged when adjacent to " making it even more difficult to read, especially with small or unusual fonts.



Source: Why is $(...) preferred over `...` (backticks)? at BashFAQ



See also:



  • POSIX standard section "2.6.3 Command Substitution"

  • POSIX rationale for including the $() syntax

  • Command Substitution

  • bash-hackers: command substitution





share|improve this answer



























    up vote
    0
    down vote













    TL;DR:



    $(...) is much preferred over `...` but backticks still work for backwards compatibly






    share|improve this answer








    New contributor




    Yehuda Schwartz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.

















      Your Answer








      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "106"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader:
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      ,
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













       

      draft saved


      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f126927%2fhave-backticks-i-e-cmd-in-sh-shells-been-deprecated%23new-answer', 'question_page');

      );

      Post as a guest






























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      115
      down vote



      accepted










      There are two different meanings of "deprecated."




      be deprecated: (chiefly of a software feature) be usable but regarded as obsolete and best avoided, typically due to having been superseded.



      —New Oxford American Dictionary




      By this definition backticks are deprecated.




      Deprecated status may also indicate the feature will be removed in the future.



      —Wikipedia




      By this definition backticks are not deprecated.



      Still supported:



      Citing the Open Group Specification on Shell Command Languages,
      specifically section "2.6.3 Command Substitution," it can be seen that both forms of command substitution, backticks (`..cmd..`) or dollar parens ($(..cmd..)) are still supported insofar as the specification goes.



      excerpt




      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`


      The shell shall expand the command substitution by executing command in a
      subshell environment (see Shell Execution Environment) and replacing the
      command substitution (the text of command plus the enclosing $() or
      backquotes) with the standard output of the command, removing sequences of one
      or more <newline> characters at the end of the substitution. Embedded <newline> characters before the end of the output shall not be removed; however,
      they may be treated as field delimiters and eliminated during field splitting,
      depending on the value of IFS and quoting that is in effect. If the output
      contains any null bytes, the behavior is unspecified.



      Within the backquoted style of command substitution, <backslash> shall retain
      its literal meaning, except when followed by: '$', '`', or <backslash>. The
      search for the matching backquote shall be satisfied by the first unquoted
      non-escaped backquote; during this search, if a non-escaped backquote is
      encountered within a shell comment, a here-document, an embedded command
      substitution of the $(command) form, or a quoted string, undefined results
      occur. A single-quoted or double-quoted string that begins, but does not end,
      within the "`...`" sequence produces undefined results.



      With the $(command) form, all characters following the open parenthesis to
      the matching closing parenthesis constitute the command. Any valid shell
      script can be used for command, except a script consisting solely of
      re-directions which produces unspecified results.




      So then why does everyone say that backticks have been deprecated?



      Because most of the use cases should be making use of the dollar parens form instead of backticks. (Deprecated in the first sense above.) Many of the most reputable sites (including U&L) often state this as well, throughout, so it's sound advice. This advice should not be confused with some non-existent plan to remove support for backticks from shells.



      • BashFAQ #082 - Why is $(...) preferred over `...` (backticks)?

      excerpt




      `...` is the legacy syntax required by only the very oldest of
      non-POSIX-compatible bourne-shells. There are several reasons to always
      prefer the $(...) syntax:



      ...




      • Bash Hackers Wiki - Obsolete and deprecated syntax

      excerpt




      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. See:
      Why is $(...) preferred over `...` (backticks)?.




      • POSIX standard rationale

      excerpt




      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.




      NOTE: This third excerpt (above) goes on to show several situations where backticks simply won't work, but the newer dollar parens method does, beginning with the following paragraph:




      Additionally, the backquoted syntax has historical restrictions on the contents of the embedded command. While the newer "$()" form can process any kind of valid embedded script, the backquoted form cannot handle some valid scripts that include backquotes.




      If you continue reading that section the failures are highlighted showing how they would fail using backticks, but do work using the newer dollar parens notation.



      Conclusions



      So it's preferable that you use dollar parens instead of backticks but you aren't actually using something that's been technically "deprecated" as in "this will stop working entirely at some planned point."



      After reading all this you should have the take away that you're strongly encouraged to use dollar parens unless you specifically require compatibility with a real original non-POSIX Bourne shell.






      share|improve this answer


















      • 25




        By most of the meanings of deprecated, I (and you) would say that backticks are deprecated. It's mostly a terminology question.
        – Stéphane Chazelas
        Apr 28 '14 at 15:54






      • 4




        @StephaneChazelas - Agreed! I will continue to tell ppl that they're deprecated but backticks have not been officially "deprecated" in the sense that they're going to be actively removed from the code base of any shell in the near future. At least none that I'm aware of.
        – slm♦
        Apr 28 '14 at 16:00






      • 3




        My interpretation is that backquotes are supported purely because they are too entrenched in existing code to formally deprecate. I have never heard an argument for continuing to use them in new code.
        – chepner
        Apr 28 '14 at 16:08






      • 2




        @chepner - neither have I, but if you come across them there may be a very good reason that someone who understands the implications might have chosen them over dollar parens. But odds are they were likely used b/c the user just didn't understand there's an alternative in dollar parens.
        – slm♦
        Apr 28 '14 at 16:14






      • 3




        @slm Yeah, I guess you did get it - I got pulled away and didn't notice. There's almost no reason to use these things, except that it can be just a little cleaner when layering subshells so $( cmd `cmd`) is just a little less messy than $( cmd $(cmd)) - it's easier to read. I've just always considered a deprecated feature in software to be one officially marked for removal by upstream - and I've never heard of anything like that. I don't care - have no love for the grave.
        – mikeserv
        Apr 28 '14 at 18:27















      up vote
      115
      down vote



      accepted










      There are two different meanings of "deprecated."




      be deprecated: (chiefly of a software feature) be usable but regarded as obsolete and best avoided, typically due to having been superseded.



      —New Oxford American Dictionary




      By this definition backticks are deprecated.




      Deprecated status may also indicate the feature will be removed in the future.



      —Wikipedia




      By this definition backticks are not deprecated.



      Still supported:



      Citing the Open Group Specification on Shell Command Languages,
      specifically section "2.6.3 Command Substitution," it can be seen that both forms of command substitution, backticks (`..cmd..`) or dollar parens ($(..cmd..)) are still supported insofar as the specification goes.



      excerpt




      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`


      The shell shall expand the command substitution by executing command in a
      subshell environment (see Shell Execution Environment) and replacing the
      command substitution (the text of command plus the enclosing $() or
      backquotes) with the standard output of the command, removing sequences of one
      or more <newline> characters at the end of the substitution. Embedded <newline> characters before the end of the output shall not be removed; however,
      they may be treated as field delimiters and eliminated during field splitting,
      depending on the value of IFS and quoting that is in effect. If the output
      contains any null bytes, the behavior is unspecified.



      Within the backquoted style of command substitution, <backslash> shall retain
      its literal meaning, except when followed by: '$', '`', or <backslash>. The
      search for the matching backquote shall be satisfied by the first unquoted
      non-escaped backquote; during this search, if a non-escaped backquote is
      encountered within a shell comment, a here-document, an embedded command
      substitution of the $(command) form, or a quoted string, undefined results
      occur. A single-quoted or double-quoted string that begins, but does not end,
      within the "`...`" sequence produces undefined results.



      With the $(command) form, all characters following the open parenthesis to
      the matching closing parenthesis constitute the command. Any valid shell
      script can be used for command, except a script consisting solely of
      re-directions which produces unspecified results.




      So then why does everyone say that backticks have been deprecated?



      Because most of the use cases should be making use of the dollar parens form instead of backticks. (Deprecated in the first sense above.) Many of the most reputable sites (including U&L) often state this as well, throughout, so it's sound advice. This advice should not be confused with some non-existent plan to remove support for backticks from shells.



      • BashFAQ #082 - Why is $(...) preferred over `...` (backticks)?

      excerpt




      `...` is the legacy syntax required by only the very oldest of
      non-POSIX-compatible bourne-shells. There are several reasons to always
      prefer the $(...) syntax:



      ...




      • Bash Hackers Wiki - Obsolete and deprecated syntax

      excerpt




      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. See:
      Why is $(...) preferred over `...` (backticks)?.




      • POSIX standard rationale

      excerpt




      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.




      NOTE: This third excerpt (above) goes on to show several situations where backticks simply won't work, but the newer dollar parens method does, beginning with the following paragraph:




      Additionally, the backquoted syntax has historical restrictions on the contents of the embedded command. While the newer "$()" form can process any kind of valid embedded script, the backquoted form cannot handle some valid scripts that include backquotes.




      If you continue reading that section the failures are highlighted showing how they would fail using backticks, but do work using the newer dollar parens notation.



      Conclusions



      So it's preferable that you use dollar parens instead of backticks but you aren't actually using something that's been technically "deprecated" as in "this will stop working entirely at some planned point."



      After reading all this you should have the take away that you're strongly encouraged to use dollar parens unless you specifically require compatibility with a real original non-POSIX Bourne shell.






      share|improve this answer


















      • 25




        By most of the meanings of deprecated, I (and you) would say that backticks are deprecated. It's mostly a terminology question.
        – Stéphane Chazelas
        Apr 28 '14 at 15:54






      • 4




        @StephaneChazelas - Agreed! I will continue to tell ppl that they're deprecated but backticks have not been officially "deprecated" in the sense that they're going to be actively removed from the code base of any shell in the near future. At least none that I'm aware of.
        – slm♦
        Apr 28 '14 at 16:00






      • 3




        My interpretation is that backquotes are supported purely because they are too entrenched in existing code to formally deprecate. I have never heard an argument for continuing to use them in new code.
        – chepner
        Apr 28 '14 at 16:08






      • 2




        @chepner - neither have I, but if you come across them there may be a very good reason that someone who understands the implications might have chosen them over dollar parens. But odds are they were likely used b/c the user just didn't understand there's an alternative in dollar parens.
        – slm♦
        Apr 28 '14 at 16:14






      • 3




        @slm Yeah, I guess you did get it - I got pulled away and didn't notice. There's almost no reason to use these things, except that it can be just a little cleaner when layering subshells so $( cmd `cmd`) is just a little less messy than $( cmd $(cmd)) - it's easier to read. I've just always considered a deprecated feature in software to be one officially marked for removal by upstream - and I've never heard of anything like that. I don't care - have no love for the grave.
        – mikeserv
        Apr 28 '14 at 18:27













      up vote
      115
      down vote



      accepted







      up vote
      115
      down vote



      accepted






      There are two different meanings of "deprecated."




      be deprecated: (chiefly of a software feature) be usable but regarded as obsolete and best avoided, typically due to having been superseded.



      —New Oxford American Dictionary




      By this definition backticks are deprecated.




      Deprecated status may also indicate the feature will be removed in the future.



      —Wikipedia




      By this definition backticks are not deprecated.



      Still supported:



      Citing the Open Group Specification on Shell Command Languages,
      specifically section "2.6.3 Command Substitution," it can be seen that both forms of command substitution, backticks (`..cmd..`) or dollar parens ($(..cmd..)) are still supported insofar as the specification goes.



      excerpt




      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`


      The shell shall expand the command substitution by executing command in a
      subshell environment (see Shell Execution Environment) and replacing the
      command substitution (the text of command plus the enclosing $() or
      backquotes) with the standard output of the command, removing sequences of one
      or more <newline> characters at the end of the substitution. Embedded <newline> characters before the end of the output shall not be removed; however,
      they may be treated as field delimiters and eliminated during field splitting,
      depending on the value of IFS and quoting that is in effect. If the output
      contains any null bytes, the behavior is unspecified.



      Within the backquoted style of command substitution, <backslash> shall retain
      its literal meaning, except when followed by: '$', '`', or <backslash>. The
      search for the matching backquote shall be satisfied by the first unquoted
      non-escaped backquote; during this search, if a non-escaped backquote is
      encountered within a shell comment, a here-document, an embedded command
      substitution of the $(command) form, or a quoted string, undefined results
      occur. A single-quoted or double-quoted string that begins, but does not end,
      within the "`...`" sequence produces undefined results.



      With the $(command) form, all characters following the open parenthesis to
      the matching closing parenthesis constitute the command. Any valid shell
      script can be used for command, except a script consisting solely of
      re-directions which produces unspecified results.




      So then why does everyone say that backticks have been deprecated?



      Because most of the use cases should be making use of the dollar parens form instead of backticks. (Deprecated in the first sense above.) Many of the most reputable sites (including U&L) often state this as well, throughout, so it's sound advice. This advice should not be confused with some non-existent plan to remove support for backticks from shells.



      • BashFAQ #082 - Why is $(...) preferred over `...` (backticks)?

      excerpt




      `...` is the legacy syntax required by only the very oldest of
      non-POSIX-compatible bourne-shells. There are several reasons to always
      prefer the $(...) syntax:



      ...




      • Bash Hackers Wiki - Obsolete and deprecated syntax

      excerpt




      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. See:
      Why is $(...) preferred over `...` (backticks)?.




      • POSIX standard rationale

      excerpt




      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.




      NOTE: This third excerpt (above) goes on to show several situations where backticks simply won't work, but the newer dollar parens method does, beginning with the following paragraph:




      Additionally, the backquoted syntax has historical restrictions on the contents of the embedded command. While the newer "$()" form can process any kind of valid embedded script, the backquoted form cannot handle some valid scripts that include backquotes.




      If you continue reading that section the failures are highlighted showing how they would fail using backticks, but do work using the newer dollar parens notation.



      Conclusions



      So it's preferable that you use dollar parens instead of backticks but you aren't actually using something that's been technically "deprecated" as in "this will stop working entirely at some planned point."



      After reading all this you should have the take away that you're strongly encouraged to use dollar parens unless you specifically require compatibility with a real original non-POSIX Bourne shell.






      share|improve this answer














      There are two different meanings of "deprecated."




      be deprecated: (chiefly of a software feature) be usable but regarded as obsolete and best avoided, typically due to having been superseded.



      —New Oxford American Dictionary




      By this definition backticks are deprecated.




      Deprecated status may also indicate the feature will be removed in the future.



      —Wikipedia




      By this definition backticks are not deprecated.



      Still supported:



      Citing the Open Group Specification on Shell Command Languages,
      specifically section "2.6.3 Command Substitution," it can be seen that both forms of command substitution, backticks (`..cmd..`) or dollar parens ($(..cmd..)) are still supported insofar as the specification goes.



      excerpt




      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`


      The shell shall expand the command substitution by executing command in a
      subshell environment (see Shell Execution Environment) and replacing the
      command substitution (the text of command plus the enclosing $() or
      backquotes) with the standard output of the command, removing sequences of one
      or more <newline> characters at the end of the substitution. Embedded <newline> characters before the end of the output shall not be removed; however,
      they may be treated as field delimiters and eliminated during field splitting,
      depending on the value of IFS and quoting that is in effect. If the output
      contains any null bytes, the behavior is unspecified.



      Within the backquoted style of command substitution, <backslash> shall retain
      its literal meaning, except when followed by: '$', '`', or <backslash>. The
      search for the matching backquote shall be satisfied by the first unquoted
      non-escaped backquote; during this search, if a non-escaped backquote is
      encountered within a shell comment, a here-document, an embedded command
      substitution of the $(command) form, or a quoted string, undefined results
      occur. A single-quoted or double-quoted string that begins, but does not end,
      within the "`...`" sequence produces undefined results.



      With the $(command) form, all characters following the open parenthesis to
      the matching closing parenthesis constitute the command. Any valid shell
      script can be used for command, except a script consisting solely of
      re-directions which produces unspecified results.




      So then why does everyone say that backticks have been deprecated?



      Because most of the use cases should be making use of the dollar parens form instead of backticks. (Deprecated in the first sense above.) Many of the most reputable sites (including U&L) often state this as well, throughout, so it's sound advice. This advice should not be confused with some non-existent plan to remove support for backticks from shells.



      • BashFAQ #082 - Why is $(...) preferred over `...` (backticks)?

      excerpt




      `...` is the legacy syntax required by only the very oldest of
      non-POSIX-compatible bourne-shells. There are several reasons to always
      prefer the $(...) syntax:



      ...




      • Bash Hackers Wiki - Obsolete and deprecated syntax

      excerpt




      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. See:
      Why is $(...) preferred over `...` (backticks)?.




      • POSIX standard rationale

      excerpt




      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.




      NOTE: This third excerpt (above) goes on to show several situations where backticks simply won't work, but the newer dollar parens method does, beginning with the following paragraph:




      Additionally, the backquoted syntax has historical restrictions on the contents of the embedded command. While the newer "$()" form can process any kind of valid embedded script, the backquoted form cannot handle some valid scripts that include backquotes.




      If you continue reading that section the failures are highlighted showing how they would fail using backticks, but do work using the newer dollar parens notation.



      Conclusions



      So it's preferable that you use dollar parens instead of backticks but you aren't actually using something that's been technically "deprecated" as in "this will stop working entirely at some planned point."



      After reading all this you should have the take away that you're strongly encouraged to use dollar parens unless you specifically require compatibility with a real original non-POSIX Bourne shell.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Dec 1 '17 at 21:18









      Wildcard

      22.4k959162




      22.4k959162










      answered Apr 28 '14 at 14:58









      slm♦

      242k66501669




      242k66501669







      • 25




        By most of the meanings of deprecated, I (and you) would say that backticks are deprecated. It's mostly a terminology question.
        – Stéphane Chazelas
        Apr 28 '14 at 15:54






      • 4




        @StephaneChazelas - Agreed! I will continue to tell ppl that they're deprecated but backticks have not been officially "deprecated" in the sense that they're going to be actively removed from the code base of any shell in the near future. At least none that I'm aware of.
        – slm♦
        Apr 28 '14 at 16:00






      • 3




        My interpretation is that backquotes are supported purely because they are too entrenched in existing code to formally deprecate. I have never heard an argument for continuing to use them in new code.
        – chepner
        Apr 28 '14 at 16:08






      • 2




        @chepner - neither have I, but if you come across them there may be a very good reason that someone who understands the implications might have chosen them over dollar parens. But odds are they were likely used b/c the user just didn't understand there's an alternative in dollar parens.
        – slm♦
        Apr 28 '14 at 16:14






      • 3




        @slm Yeah, I guess you did get it - I got pulled away and didn't notice. There's almost no reason to use these things, except that it can be just a little cleaner when layering subshells so $( cmd `cmd`) is just a little less messy than $( cmd $(cmd)) - it's easier to read. I've just always considered a deprecated feature in software to be one officially marked for removal by upstream - and I've never heard of anything like that. I don't care - have no love for the grave.
        – mikeserv
        Apr 28 '14 at 18:27













      • 25




        By most of the meanings of deprecated, I (and you) would say that backticks are deprecated. It's mostly a terminology question.
        – Stéphane Chazelas
        Apr 28 '14 at 15:54






      • 4




        @StephaneChazelas - Agreed! I will continue to tell ppl that they're deprecated but backticks have not been officially "deprecated" in the sense that they're going to be actively removed from the code base of any shell in the near future. At least none that I'm aware of.
        – slm♦
        Apr 28 '14 at 16:00






      • 3




        My interpretation is that backquotes are supported purely because they are too entrenched in existing code to formally deprecate. I have never heard an argument for continuing to use them in new code.
        – chepner
        Apr 28 '14 at 16:08






      • 2




        @chepner - neither have I, but if you come across them there may be a very good reason that someone who understands the implications might have chosen them over dollar parens. But odds are they were likely used b/c the user just didn't understand there's an alternative in dollar parens.
        – slm♦
        Apr 28 '14 at 16:14






      • 3




        @slm Yeah, I guess you did get it - I got pulled away and didn't notice. There's almost no reason to use these things, except that it can be just a little cleaner when layering subshells so $( cmd `cmd`) is just a little less messy than $( cmd $(cmd)) - it's easier to read. I've just always considered a deprecated feature in software to be one officially marked for removal by upstream - and I've never heard of anything like that. I don't care - have no love for the grave.
        – mikeserv
        Apr 28 '14 at 18:27








      25




      25




      By most of the meanings of deprecated, I (and you) would say that backticks are deprecated. It's mostly a terminology question.
      – Stéphane Chazelas
      Apr 28 '14 at 15:54




      By most of the meanings of deprecated, I (and you) would say that backticks are deprecated. It's mostly a terminology question.
      – Stéphane Chazelas
      Apr 28 '14 at 15:54




      4




      4




      @StephaneChazelas - Agreed! I will continue to tell ppl that they're deprecated but backticks have not been officially "deprecated" in the sense that they're going to be actively removed from the code base of any shell in the near future. At least none that I'm aware of.
      – slm♦
      Apr 28 '14 at 16:00




      @StephaneChazelas - Agreed! I will continue to tell ppl that they're deprecated but backticks have not been officially "deprecated" in the sense that they're going to be actively removed from the code base of any shell in the near future. At least none that I'm aware of.
      – slm♦
      Apr 28 '14 at 16:00




      3




      3




      My interpretation is that backquotes are supported purely because they are too entrenched in existing code to formally deprecate. I have never heard an argument for continuing to use them in new code.
      – chepner
      Apr 28 '14 at 16:08




      My interpretation is that backquotes are supported purely because they are too entrenched in existing code to formally deprecate. I have never heard an argument for continuing to use them in new code.
      – chepner
      Apr 28 '14 at 16:08




      2




      2




      @chepner - neither have I, but if you come across them there may be a very good reason that someone who understands the implications might have chosen them over dollar parens. But odds are they were likely used b/c the user just didn't understand there's an alternative in dollar parens.
      – slm♦
      Apr 28 '14 at 16:14




      @chepner - neither have I, but if you come across them there may be a very good reason that someone who understands the implications might have chosen them over dollar parens. But odds are they were likely used b/c the user just didn't understand there's an alternative in dollar parens.
      – slm♦
      Apr 28 '14 at 16:14




      3




      3




      @slm Yeah, I guess you did get it - I got pulled away and didn't notice. There's almost no reason to use these things, except that it can be just a little cleaner when layering subshells so $( cmd `cmd`) is just a little less messy than $( cmd $(cmd)) - it's easier to read. I've just always considered a deprecated feature in software to be one officially marked for removal by upstream - and I've never heard of anything like that. I don't care - have no love for the grave.
      – mikeserv
      Apr 28 '14 at 18:27





      @slm Yeah, I guess you did get it - I got pulled away and didn't notice. There's almost no reason to use these things, except that it can be just a little cleaner when layering subshells so $( cmd `cmd`) is just a little less messy than $( cmd $(cmd)) - it's easier to read. I've just always considered a deprecated feature in software to be one officially marked for removal by upstream - and I've never heard of anything like that. I don't care - have no love for the grave.
      – mikeserv
      Apr 28 '14 at 18:27













      up vote
      12
      down vote













      It's not deprecated, but the backticks (`...`) is the legacy syntax required by only the very oldest of non-POSIX-compatible bourne-shells and $(...) is POSIX and more preferred for several reasons:




      • Backslashes () inside backticks are handled in a non-obvious manner:



        $ echo "`echo \a`" "$(echo \a)"
        a a
        $ echo "`echo \\a`" "$(echo \\a)"
        a \a
        # Note that this is true for *single quotes* too!
        $ foo=`echo '\'`; bar=$(echo '\'); echo "foo is $foo, bar is $bar"
        foo is , bar is \



      • Nested quoting inside $() is far more convenient:



        echo "x is $(sed ... <<<"$y")"


        instead of:



        echo "x is `sed ... <<<"$y"`"


        or writing something like:



        IPs_inna_string=`awk "/`cat /etc/myname`/"'print $1' /etc/hosts`


        because $() uses an entirely new context for quoting



        which is not portable as Bourne and Korn shells would require these backslashes, while Bash and dash don't.




      • Syntax for nesting command substitutions is easier:



        x=$(grep "$(dirname "$path")" file)


        than:



        x=`grep "`dirname "$path"`" file`


        because $() enforces an entirely new context for quoting, so each command substitution is protected and can be treated on its own without special concern over quoting and escaping. When using backticks, it gets uglier and uglier after two and above levels.



        Few more examples:



        echo `echo `ls`` # INCORRECT
        echo `echo `ls`` # CORRECT
        echo $(echo $(ls)) # CORRECT



      • It solves a problem of inconsistent behavior when using backquotes:




        • echo '$x' outputs $x


        • echo `echo '$x'` outputs $x


        • echo $(echo '$x') outputs $x



      • Backticks syntax has historical restrictions on the contents of the embedded command and cannot handle some valid scripts that include backquotes, while the newer $() form can process any kind of valid embedded script.



        For example, these otherwise valid embedded scripts do not work in the left column, but do work on the rightIEEE:



        echo ` echo $(
        cat <<eof cat <<eof
        a here-doc with ` a here-doc with )
        eof eof
        ` )


        echo ` echo $(
        echo abc # a comment with ` echo abc # a comment with )
        ` )


        echo ` echo $(
        echo '`' echo ')'
        ` )


      Therefore the syntax for $-prefixed command substitution should be the preferred method, because it is visually clear with clean syntax (improves human and machine readability), it is nestable and intuitive, its inner parsing is separate, and it is also more consistent (with all other expansions that are parsed from within double-quotes) where backticks are the only exception and ` character is easily camouflaged when adjacent to " making it even more difficult to read, especially with small or unusual fonts.



      Source: Why is $(...) preferred over `...` (backticks)? at BashFAQ



      See also:



      • POSIX standard section "2.6.3 Command Substitution"

      • POSIX rationale for including the $() syntax

      • Command Substitution

      • bash-hackers: command substitution





      share|improve this answer
























        up vote
        12
        down vote













        It's not deprecated, but the backticks (`...`) is the legacy syntax required by only the very oldest of non-POSIX-compatible bourne-shells and $(...) is POSIX and more preferred for several reasons:




        • Backslashes () inside backticks are handled in a non-obvious manner:



          $ echo "`echo \a`" "$(echo \a)"
          a a
          $ echo "`echo \\a`" "$(echo \\a)"
          a \a
          # Note that this is true for *single quotes* too!
          $ foo=`echo '\'`; bar=$(echo '\'); echo "foo is $foo, bar is $bar"
          foo is , bar is \



        • Nested quoting inside $() is far more convenient:



          echo "x is $(sed ... <<<"$y")"


          instead of:



          echo "x is `sed ... <<<"$y"`"


          or writing something like:



          IPs_inna_string=`awk "/`cat /etc/myname`/"'print $1' /etc/hosts`


          because $() uses an entirely new context for quoting



          which is not portable as Bourne and Korn shells would require these backslashes, while Bash and dash don't.




        • Syntax for nesting command substitutions is easier:



          x=$(grep "$(dirname "$path")" file)


          than:



          x=`grep "`dirname "$path"`" file`


          because $() enforces an entirely new context for quoting, so each command substitution is protected and can be treated on its own without special concern over quoting and escaping. When using backticks, it gets uglier and uglier after two and above levels.



          Few more examples:



          echo `echo `ls`` # INCORRECT
          echo `echo `ls`` # CORRECT
          echo $(echo $(ls)) # CORRECT



        • It solves a problem of inconsistent behavior when using backquotes:




          • echo '$x' outputs $x


          • echo `echo '$x'` outputs $x


          • echo $(echo '$x') outputs $x



        • Backticks syntax has historical restrictions on the contents of the embedded command and cannot handle some valid scripts that include backquotes, while the newer $() form can process any kind of valid embedded script.



          For example, these otherwise valid embedded scripts do not work in the left column, but do work on the rightIEEE:



          echo ` echo $(
          cat <<eof cat <<eof
          a here-doc with ` a here-doc with )
          eof eof
          ` )


          echo ` echo $(
          echo abc # a comment with ` echo abc # a comment with )
          ` )


          echo ` echo $(
          echo '`' echo ')'
          ` )


        Therefore the syntax for $-prefixed command substitution should be the preferred method, because it is visually clear with clean syntax (improves human and machine readability), it is nestable and intuitive, its inner parsing is separate, and it is also more consistent (with all other expansions that are parsed from within double-quotes) where backticks are the only exception and ` character is easily camouflaged when adjacent to " making it even more difficult to read, especially with small or unusual fonts.



        Source: Why is $(...) preferred over `...` (backticks)? at BashFAQ



        See also:



        • POSIX standard section "2.6.3 Command Substitution"

        • POSIX rationale for including the $() syntax

        • Command Substitution

        • bash-hackers: command substitution





        share|improve this answer






















          up vote
          12
          down vote










          up vote
          12
          down vote









          It's not deprecated, but the backticks (`...`) is the legacy syntax required by only the very oldest of non-POSIX-compatible bourne-shells and $(...) is POSIX and more preferred for several reasons:




          • Backslashes () inside backticks are handled in a non-obvious manner:



            $ echo "`echo \a`" "$(echo \a)"
            a a
            $ echo "`echo \\a`" "$(echo \\a)"
            a \a
            # Note that this is true for *single quotes* too!
            $ foo=`echo '\'`; bar=$(echo '\'); echo "foo is $foo, bar is $bar"
            foo is , bar is \



          • Nested quoting inside $() is far more convenient:



            echo "x is $(sed ... <<<"$y")"


            instead of:



            echo "x is `sed ... <<<"$y"`"


            or writing something like:



            IPs_inna_string=`awk "/`cat /etc/myname`/"'print $1' /etc/hosts`


            because $() uses an entirely new context for quoting



            which is not portable as Bourne and Korn shells would require these backslashes, while Bash and dash don't.




          • Syntax for nesting command substitutions is easier:



            x=$(grep "$(dirname "$path")" file)


            than:



            x=`grep "`dirname "$path"`" file`


            because $() enforces an entirely new context for quoting, so each command substitution is protected and can be treated on its own without special concern over quoting and escaping. When using backticks, it gets uglier and uglier after two and above levels.



            Few more examples:



            echo `echo `ls`` # INCORRECT
            echo `echo `ls`` # CORRECT
            echo $(echo $(ls)) # CORRECT



          • It solves a problem of inconsistent behavior when using backquotes:




            • echo '$x' outputs $x


            • echo `echo '$x'` outputs $x


            • echo $(echo '$x') outputs $x



          • Backticks syntax has historical restrictions on the contents of the embedded command and cannot handle some valid scripts that include backquotes, while the newer $() form can process any kind of valid embedded script.



            For example, these otherwise valid embedded scripts do not work in the left column, but do work on the rightIEEE:



            echo ` echo $(
            cat <<eof cat <<eof
            a here-doc with ` a here-doc with )
            eof eof
            ` )


            echo ` echo $(
            echo abc # a comment with ` echo abc # a comment with )
            ` )


            echo ` echo $(
            echo '`' echo ')'
            ` )


          Therefore the syntax for $-prefixed command substitution should be the preferred method, because it is visually clear with clean syntax (improves human and machine readability), it is nestable and intuitive, its inner parsing is separate, and it is also more consistent (with all other expansions that are parsed from within double-quotes) where backticks are the only exception and ` character is easily camouflaged when adjacent to " making it even more difficult to read, especially with small or unusual fonts.



          Source: Why is $(...) preferred over `...` (backticks)? at BashFAQ



          See also:



          • POSIX standard section "2.6.3 Command Substitution"

          • POSIX rationale for including the $() syntax

          • Command Substitution

          • bash-hackers: command substitution





          share|improve this answer












          It's not deprecated, but the backticks (`...`) is the legacy syntax required by only the very oldest of non-POSIX-compatible bourne-shells and $(...) is POSIX and more preferred for several reasons:




          • Backslashes () inside backticks are handled in a non-obvious manner:



            $ echo "`echo \a`" "$(echo \a)"
            a a
            $ echo "`echo \\a`" "$(echo \\a)"
            a \a
            # Note that this is true for *single quotes* too!
            $ foo=`echo '\'`; bar=$(echo '\'); echo "foo is $foo, bar is $bar"
            foo is , bar is \



          • Nested quoting inside $() is far more convenient:



            echo "x is $(sed ... <<<"$y")"


            instead of:



            echo "x is `sed ... <<<"$y"`"


            or writing something like:



            IPs_inna_string=`awk "/`cat /etc/myname`/"'print $1' /etc/hosts`


            because $() uses an entirely new context for quoting



            which is not portable as Bourne and Korn shells would require these backslashes, while Bash and dash don't.




          • Syntax for nesting command substitutions is easier:



            x=$(grep "$(dirname "$path")" file)


            than:



            x=`grep "`dirname "$path"`" file`


            because $() enforces an entirely new context for quoting, so each command substitution is protected and can be treated on its own without special concern over quoting and escaping. When using backticks, it gets uglier and uglier after two and above levels.



            Few more examples:



            echo `echo `ls`` # INCORRECT
            echo `echo `ls`` # CORRECT
            echo $(echo $(ls)) # CORRECT



          • It solves a problem of inconsistent behavior when using backquotes:




            • echo '$x' outputs $x


            • echo `echo '$x'` outputs $x


            • echo $(echo '$x') outputs $x



          • Backticks syntax has historical restrictions on the contents of the embedded command and cannot handle some valid scripts that include backquotes, while the newer $() form can process any kind of valid embedded script.



            For example, these otherwise valid embedded scripts do not work in the left column, but do work on the rightIEEE:



            echo ` echo $(
            cat <<eof cat <<eof
            a here-doc with ` a here-doc with )
            eof eof
            ` )


            echo ` echo $(
            echo abc # a comment with ` echo abc # a comment with )
            ` )


            echo ` echo $(
            echo '`' echo ')'
            ` )


          Therefore the syntax for $-prefixed command substitution should be the preferred method, because it is visually clear with clean syntax (improves human and machine readability), it is nestable and intuitive, its inner parsing is separate, and it is also more consistent (with all other expansions that are parsed from within double-quotes) where backticks are the only exception and ` character is easily camouflaged when adjacent to " making it even more difficult to read, especially with small or unusual fonts.



          Source: Why is $(...) preferred over `...` (backticks)? at BashFAQ



          See also:



          • POSIX standard section "2.6.3 Command Substitution"

          • POSIX rationale for including the $() syntax

          • Command Substitution

          • bash-hackers: command substitution






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Oct 24 '15 at 17:05









          kenorb

          7,951365105




          7,951365105




















              up vote
              0
              down vote













              TL;DR:



              $(...) is much preferred over `...` but backticks still work for backwards compatibly






              share|improve this answer








              New contributor




              Yehuda Schwartz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
              Check out our Code of Conduct.





















                up vote
                0
                down vote













                TL;DR:



                $(...) is much preferred over `...` but backticks still work for backwards compatibly






                share|improve this answer








                New contributor




                Yehuda Schwartz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.



















                  up vote
                  0
                  down vote










                  up vote
                  0
                  down vote









                  TL;DR:



                  $(...) is much preferred over `...` but backticks still work for backwards compatibly






                  share|improve this answer








                  New contributor




                  Yehuda Schwartz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.









                  TL;DR:



                  $(...) is much preferred over `...` but backticks still work for backwards compatibly







                  share|improve this answer








                  New contributor




                  Yehuda Schwartz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.









                  share|improve this answer



                  share|improve this answer






                  New contributor




                  Yehuda Schwartz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.









                  answered 10 mins ago









                  Yehuda Schwartz

                  1013




                  1013




                  New contributor




                  Yehuda Schwartz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.





                  New contributor





                  Yehuda Schwartz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.






                  Yehuda Schwartz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.



























                       

                      draft saved


                      draft discarded















































                       


                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f126927%2fhave-backticks-i-e-cmd-in-sh-shells-been-deprecated%23new-answer', 'question_page');

                      );

                      Post as a guest













































































                      Popular posts from this blog

                      How to check contact read email or not when send email to Individual?

                      Displaying single band from multi-band raster using QGIS

                      How many registers does an x86_64 CPU actually have?