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

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?

Solution 1

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.

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)?

  `...` 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

  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

  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.

Solution 2

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 right^IEEE:

  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

Comments

[Overmind Jiang]

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.

[Trevor Boyd Smith]

punch line here

[Christopher]

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.osdev‌​ice/…

[denis]

I have a definite difference in "GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin14)" on mac 10.10: matchingLines=$( grep -n '\$-PARAMETER' ... | ... ) works, matchingLines= backtick the same stuff backtick doesn't work -- seems to lose the backslash in backslash-dollar. (It's not my script ...)

[Polluks]

@denis ...and you cannot use backticks in these kind of comments ;-)

[mikeserv]

preferred by whom? Your backslash was eaten up there by literal meaning by the way.,

[slm]

@mikeserv - by the community and the sources I've cited. I would liken the whole thing to goto's in Basic. They're generally discouraged but in capable hands are not the pariahs that they've been made out to be.

[Stéphane Chazelas]

By most of the meanings of deprecated, I (and you) would say that backticks are deprecated. It's mostly a terminology question.

[slm]

@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.

[chepner]

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.

[slm]

@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.

[mikeserv]

@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.

[Nanopixel]

@slm: Deprecated does not necessarily mean removed functionality. More like a warning.

[slm]

@staticx - correct, except in this case there is neither a formal deprecation notice nor a warning which is typically been the case, in my experience, when a "feature" is being planned for removal.

[Nanopixel]

@slm: unlike Java, bash rarely gets updated by administrators. Java packages deprecated warnings

[ssola]

@slm note, though, that (unlike gotos) use of backticks will not cause you to be eaten by raptors. Unless you nest them.

[mikeserv]

@kojiro - agreed. I have also noticed raptors are conspicuously anti-nest

[jw013]

You may want to add the following quote from the POSIX standard rationale: 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. While this is not a formal deprecation since the rationale section is informative and not normative, it does suggest that continued use of backticks should be avoided.

[slm]

@jw013 - thanks, I've added several bits from that section even though I'd linked to it earlier in the A. I believe you're correct in that that point should be highlighted directly in this A.

[mikeserv]

@jw013 , slm - in your original link the very next paragraph notes possible issues when nesting (subshells) within $(substitutions) and the same link jw provides expands on this only a couple of paragraphs below - citing implementation dependent heuristics as the likelihood that such things will be parsed correctly. So the `backtick has issues nesting the `backtick and (parens) have issues nesting (parens). Go figure.

[jw013]

@mikeserv There are no issues nesting subshells in command substitutions as long as you read and follow the standard carefully. This standard requires that conforming applications always separate the "$(" and '(' with white space when a command substitution starts with a subshell. There, problem solved. The standard says that $((subshell)) parsing is unspecified behavior and varies by implementation, so if you write that and get non-portable behavior, that is your own fault. This seems like a really desperate attempt to "justify" the use of backticks. It's not working.

[jw013]

@mikeserv You should learn the difference between command substitution, subshell, and arithmetic substitution. "(parens) has issues nesting (parens)" means absolutely nothing because (parens) is not a thing. Are you talking about command substitution, arithmetic expansion, or subshells? All of them nest just fine.

[mikeserv]

@jw013 - obviously there are issues or the workaround need not have been implemented - there are in fact several paragraphs worth of it in your own link from earlier, in that same section and more further below about ((expression)). You can believe what you like about my motives - i dont care - but the point is the only way to write good code is to develop a practical understanding of the limitations of what you write. Now, if youll excuse me, ive got to debug this $`1++` increment that just wont work like i mean it to for some reason...

[jw013]

@mikeserv ((expression)) is a bash-ism. At this point you have lost me. What are you talking about?

[mikeserv]

@jw013 - Agreed. From your link: The requirement for conforming applications to separate two leading '(' characters with white space if a grouping command would be parsed as an arithmetic expansion if preceded by a '$' is to allow shells which implement the "(( arithmetic expression ))" extension to apply the same disambiguation rules consistently to $((...)) and ((...)). Heading: Grouping Commands - but theres more above and in the final docs proper of course. To be honest I just enjoyed the read - there are some very interesting examples I haven't seen before scattered throughout.

[Nikos Alexandris]

ShellCheck also indicates deprecation: github.com/koalaman/shellcheck/wiki/SC2006. Just a comment: What a pity, visually I prefer the backticks.

[Wildcard]

@slm, hope you don't mind my edit. I got tired of pointing contentious people here and having them come back with, "It says they're not deprecated, so there's no reason for me to stop using them." Contentious people don't like to read....

[pmiguelpinto]

Interesting, the example in the "third excerpt" is exactly why I prefer backticks over dollar parens...