Some shell scripts I have come across use the following syntax when defining variables:

file_list_1=$(echo "list.txt")


file_list_2=$(find ./)

I would have used:



file_list_2=`find ./`

I'm not sure which if any of the above are better or safer. What is the benefit of using the syntax x=$( ) when setting a variable?


From the manual (man bash):

$(command)  or  `command`

Bash performs the expansion by executing command and replacing the command substitution with the standard output of the command, with any trailing newlines deleted. Embedded newlines are not deleted, but they may be removed during word splitting. The command substitution $(cat file) can be replaced by the equivalent but faster $(< file).

When the old-style backquote form of substitution is used, backslash retains its literal meaning except when followed by $, `, or \. The first backquote not preceded by a backslash terminates the command substitution. When using the $(command) form, all characters between the parentheses make up the command; none are treated specially.

The POSIX standard defines the $() form of command substitution. $() allows nested commands and looks better (legibility). It should be available on all Bourne shells.

You can read more on IEEE Std 1003.1, Shell Command Language, Section 2.6.3 Command Substitution.

At least one Unix, AIX, has documented that backticks are obsolete. From that link:

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.

However, /bin/sh does not have to be POSIX compliant. So there is still sometimes a case for backticks in the real world, as @Jeight points out.

  • Is there any point in using command substitution to define a variable statically, as in file_list_1=$(echo "list.txt")? Maybe for special characters?
    – Chris R
    May 21 '15 at 23:53
  • I take it you don't work with older UNIX systems that often? Obsolete maybe by modern standards yes.
    – Jeight
    May 22 '15 at 0:30
  • Sorry. I didn't mean to come across so harsh. I just have to create backward compatible scripts everyday. This is by far the better and more complete answer.
    – Jeight
    May 22 '15 at 0:38
  • 1
    @Christopher: You say “The POSIX standard defines the $() form of command substitution. $() allows nested commands”.  True.  Also, the POSIX standard defines the `…` form of command substitution, and `…` allows nested commands (cmd₃ … `cmd₂ … \`cmd₁ …\` …` …). May 22 '15 at 3:40
  • 1
    @G-Man; With backtics nesting requires escapes, as you've showed. - How would another level of nesting be implemented? How would consistent double-quoting on each level be implemented? - Short answer; use $(...) instead.
    – Janis
    May 22 '15 at 6:32

It's a lot of personal preference. Using a backtick to signify a command would be more POSIX compatible with older systems. The $() is more modern and is easier to read for some people. I would personally never use file_list_1=$(echo "list.txt"). It seems to ugly and has no additional use.

  • That's not correct. May 21 '15 at 23:18
  • @DisplayName Really? Why don't you clarify? The answer from CHristopher is referring to bash, but what if you are using an older HPUX that uses sh or ksh... is $() POSIX compatible then? The only thing I left out was the litteral meaning of the entire command when using $() and not backticks. That can cause problems when you have nested quotations in your command. So like I said a lot of personal preference.
    – Jeight
    May 22 '15 at 0:07
  • I did mean all Bourne shells (ash, bash, dash, zsh, etc), not just the Bourne Again Shell (BASH). May 22 '15 at 0:13
  • I understand, but you are talking modern shells, and I'm including older shells as well such as csh and sh. Look at efytimes.com/e1/creativenews.asp?edid=123101
    – Jeight
    May 22 '15 at 0:26
  • 3
    @Jeight; There's confusing and misleading text above; "more POSIX compatible" ("more"?) and "is $() POSIX compatible" - those make no sense. - Note that $(...) is defined by POSIX, and any shell claiming to be POSIX compatible has to support it. Note also that older commercial Unixes (e.g. AIX, HP-UX) had ksh88, and ksh88 supported not only $(...) but invented it, and moreover, ksh88 was also the base for the POSIX definition. - The backtics, OTOH, have issues (see references), though, and are deprecated; there's no reason to use them, but reasons to abstain from using them.
    – Janis
    May 22 '15 at 6:24

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.