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. – Stéphane Chazelas Oct 1 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. – Paul_Pedant Oct 1 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. – user414777 Oct 1 at 16:18
  • 3
    I prefer using $() over backticks because it makes the code look cleaner to me. – Peschke Oct 1 at 17:19
  • 2
    The main reason to not use backticks in the code is that they are for code highlighting here. – Paŭlo Ebermann Oct 2 at 3:32

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

| improve this answer | |
  • great answer - the one less thing to think about is a strong point – Steven Penny Oct 2 at 2:02

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. :)

| improve this answer | |
  • 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 supports Monica Oct 7 at 18:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.