The old ticks vs parentheses issue: confused

Question

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?

Answer 1

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

Answer 2

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