Since being corrected many years ago, I switched from backticks to $() for command expansion.

But I still prefer the backticks. It is fewer keystrokes and does not involve the Shift key.

I understand that the parentheses are preferable because it is less prone to the errors that backticks is prone to, but what is the reason for the rule to never use backticks?

  • 6
    See also How to use a special character as a normal one?. backticks can only be used portably and reliably in scalar variable assignments. Oct 1, 2020 at 10:10
  • 6
    Apart from technical issues: I just got fed up with posting solutions with ... where people just put them in as single quotes or double quotes or UTF-8 apostrophes, and then badmouthed me for posting solutions that didn't work when I knew I had tested them. $( .. ) is a visual trigger when you are debugging, where you might not eyeball back-ticks. I even saw a malicious post on LinixMint forum where somebody hid rm -rf * as an arg to a complex command line in an answer. Oct 1, 2020 at 11:34
  • 6
    There's no such "rule" to never use backticks. But avoid using backticks when posting on unix.se, unless you deliberately want to trigger some people.
    – user313992
    Oct 1, 2020 at 16:18
  • 3
    I prefer using $() over backticks because it makes the code look cleaner to me.
    – Peschke
    Oct 1, 2020 at 17:19
  • 3
    The main reason to not use backticks in the code is that they are for code highlighting here. Oct 2, 2020 at 3:32

2 Answers 2


The Bash FAQ gives a number of reasons to prefer parentheses to backticks, but there isn’t a universal rule that you shouldn’t ever use backticks.

The main reason to prefer parentheses in my view is that parsing inside $() is consistent with parsing performed outside, which isn’t the case with backticks. This means that you can take a shell command and wrap it with "$()" without much thought; that’s not true if you use backticks instead. This cascades, so wrapping a command which itself contains a substitution is easily done with "$()", not so with backticks.

Ultimately I think it’s a question of habit. If you choose to use backticks for simple cases, parentheses for others, you’ll have to make that choice every time you want to substitute a command. If you choose to always use parentheses, you never have to think about it again.

The latter can explain the presence of a “don’t use backticks” rule in certain coding guides: it simplifies development, and removes a source of errors for developers and reviewers. It also explains why using parentheses can be recommended even for one-liners: it’s hard to ingrain a habit for script-writing when it’s not applied everywhere.

(As far as keying goes, that depends on the keyboard layout; on my AZERTY keyboard, $() doesn’t involve any shifting, whereas backticks are quite painful to write.)


Personally, I would use $(...), always, just because it's more consistent in the corner cases of nested quotes and expansions, and I like the idea of having expansions start consistently with a dollar sign, and the parenthesis are more visible than backticks which are rather light in some fonts, and can get confused with single quotes like mentioned in the comments. But other than the first, those are about looks and aesthetics, so your opinion may well differ.

Based on the discussion in Have backticks (i.e. `cmd`) in *sh shells been deprecated?, it doesn't seem that support for backticks would be on track to be removed, so that's not a reason to say "never".

However, note that the parsing of backticks works oddly in some cases. Having to add extra backticks for nested expansions is rather simple:

echo `echo \`echo foo\` `

But that's not all. As Stéphane notes in an answer to How to use a special character as a normal one?, even nesting double quotes with backticks in the between fails in ksh, for example (I'll reproduce this one here for easier access):

ksh$ echo "`date +"%F %T"`"  
ksh: : cannot execute [Is a directory]
2020-10-01 %T

and you have to escape the inner double quotes too, even though this looks like it would be unambiguous to parse even without them:

ksh$ echo "`date +\"%F %T\"`"  
2020-10-01 14:14:27

(The quotes around the command substitution are relevant because of command substitution, though not with echo here.)

So, while this does seem like a case of "never say never", and while backticks work fine in the simple cases, I think there's enough to strongly suggest just using $() instead. :)

  • Simplifying nested expressions is very important. Also huge: avoiding backslashes as much as possible, by pretty much whatever means necessary. Escaping metacharacters and escaping escape characters is a great recipe for confusion, unreadable and incomprehensible code, and bugs including security holes.
    – jrw32982
    Oct 7, 2020 at 18:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .