This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Shell Programming: What's the difference between $(command) and command
It seems there is no difference between
$()
and
``
For example,
$(date)
is the same as
`date`
Any suggestion ?
What's the difference between man command and stackoverflow.com? :)
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.
so, if you put date inside, it's more or less the same.
Related
This question already has answers here:
Difference between single and double quotes in Bash
(7 answers)
Closed 1 year ago.
USER_UID=$1
echo 'generate_token("$USER_UID")'
I want output like
generate_token("1234567")
i tried multiple ways but didn't worked. it just print same line without value generate_jwt("$USER_UID")
When you use single quotes, it causes the shell to preserve the literal value of each character within the quotes. This means the $ will be treated as a literal $ character.
You should use double quotes:
USER_UID="$1"
echo "generate_token(\"$USER_UID\")"
From the bash man page, under the Quoting section:
Enclosing characters in double quotes preserves the literal value of all characters within the quotes, with the exception of $, `, \, and, when history expansion is enabled, !.
For POSIX details on quoting, see here.
Example in an interactive shell:
$ USER_UID='foo'
$ echo "generate_token(\"$USER_UID\")"
generate_token("foo")
This will also work if USER_UID contains spaces:
$ USER_UID='var with spaces'
$ echo "generate_token(\"$USER_UID\")"
generate_token("var with spaces")
This question already has answers here:
What is the benefit of using $() instead of backticks in shell scripts? [duplicate]
(9 answers)
Closed 4 years ago.
Can I always expect the same results from these two forms?
For example:
for i in `seq 1 10`
for i in $(seq 1 10)
I've got the same result from the above two statements.
The difference between the two is in the treatment of special characters.
From the man page:
Command Substitution
Command substitution allows the output of a command to replace the
command name. There are two forms:
$(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.
With the $() form, you don't need to worry about escaping any special characters. This can be helpful if you have a complicated command that you just want to drop in place.
The backquoted form is useful when you want to do any kind of substitution within the command.
Here's an example of when the two differ:
XXX=x1.sh
YYY=`ls -l \$XXX`
ZZZ=$(ls -l \$XXX)
echo YYY = $YYY
echo ZZZ = $ZZZ
Output:
ls: cannot access $XXX: No such file or directory
YYY = -rwxr-xr-x. 1 dbush dbush 94 Apr 14 23:04 x1.sh
ZZZ =
This question already has answers here:
Is it necessary to quote command substitutions during variable assignment in bash?
(3 answers)
Closed 6 years ago.
I always thought I must put quotes around $() in bash, like in:
FOO="$(echo "bar baz")"
but apparently this is unnecessary, at least during variable assignment:
$ FOO=$(echo "foo bar")
$ echo "$FOO"
foo bar
On the other hand, if I just try to assign multiple words to a variable, I get an error, because it's interpreted as "set variable for duration of subsequent command":
$ FOO=bar fooooo
fooooo: command not found
Also, if I just use $() without quotes in non-assignment context, they're again treated as separate words:
$ echo $(echo "baa beee")
baa beee
So, what are the rules regarding $() and "" interaction, and how safe is the non-quote variant? I'd be especially grateful for manpage quotes, or some other authoritative references. Also, is there some "good practice/style" here?
In brief, quotes are necessary to suppress otherwise normal behavior. In most contexts, you would need to quote the command substitution to suppress word-splitting and pathname expansion.
From the man page, under "Command substitution":
If the [command] substitution appears within double quotes, word
splitting and pathname expansion are not performed on the results.
However, the right-hand side of an assignment is not one of those contexts. From the man page, under "PARAMETERS":
A variable may be assigned to by a statement of the form
name=[value]
If value is not given, the variable is assigned the null string. All values
undergo tilde expansion, parameter and variable expansion, command substitution,
arithmetic expansion, and quote removal (see EXPANSION below).
Note that neither word splitting nor pathname expansion are mentioned.
As a rule, when in doubt, quote any expansion. The times when you want word-splitting and pathname expansion of an expansion are rare and usually obvious.
This question already has an answer here:
-bash: !": event not found [closed]
(1 answer)
Closed 6 years ago.
Simply run
echo "This is a **test** see "
You get:
bash: 
use single quotes
echo 'This is a **test** see '
single quotes take the test you pass as verbatim. While double quoted strings are interpreted by bash, for instance $VAR would indicate a variable, $(..) would execute a command and insert the stdout, and [...] are treated as boolean evaluator and ! as NOT, and so on. From the bash manual:
Enclosing characters in double quotes preserves the literal value of all characters within the quotes, with the exception of $, , \, and, when history expansion is enabled, !. The characters $ and retain their special meaning withindouble quotes. The backslash retains its special meaning only when followed by one of the following characters: $, `, ", \, or . A double quote may be quoted within double quotes by preceding it with a backslash. If enabled, history expansion will be performed unless an ! appearing in double quotes is escaped using a backslash. The backslash preceding the ! is not removed.
The ! is interpreted as the NOT (logical NOT) operator and thus [alt is treated as a command. Using single quotes is probably the best option here:
echo 'This is a **test** see '
This question already has answers here:
here document and double backslash
(2 answers)
Closed 8 years ago.
I am trying to pass some code to a REPL and this heredoc seems to be escaping my regex. To shorten the problem... I have a really long regex but this is the main problem:
<<SOMECODE
\\d
SOMECODE
This is returned by the heredoc as
\d
How do I get the heredoc to not remove my extra slash? I thought heredocs were immune to characters.
Quote Your Here-Document Delimiter
If you want to prevent most escapes and expansions, you can surround your Bash here-document delimiter with single quotes. For example:
cat << 'SOMECODE'
\\d
SOMECODE
prints \\d on my system.