Some shell scripts I have come across use the following syntax when defining variables:
file_list_1=$(echo "list.txt")
or
file_list_2=$(find ./)
I would have used:
file_list_1="list.txt"
and
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
$(catfile)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.
file_list_1=$(echo "list.txt")? Maybe for special characters?
$() 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₁ …\` …` …).
$(...) instead.
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.
$(...) 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.
file_list_1=$(echo "list.txt")instead offile_list_1="list.txt". That would be slower (unnecessaryechocommand), more error prone (in case of special characters) and less readable. I would use single quotes however:file_list_1='list.txt'- that would be even more solid.`...`is a pain, while$(...)is a lot saner.