In regular, unquoted situations, every character with a backslash preceding it has it's backslash processed, whether it needs it or not.
But inside quotes or a heredoc, only the few listed characters are treated specially. Backslashes preceding all other regular characters will remain literal.
command + # output + # explanation:
A heredoc does not process quotemarks, but it does process "
$" and "
`", so substitutions still happen. It also processes backslashes if they are in front of the reserved characters, allowing you to escape them if needed. All other characters are ignored just as in the quoted situation above.
Note that if the delimiting word (the opening EOF) is quoted or backslashed, it won't process anything. The entire text will become literal.
As for this:
The way
`..` processes backslashes appears to be rather confusing overall. See
here. It appears to be doing some kind of double-expansion, in fact.
$(..), on the other hand, simply processes everything it contains as a regular command subshell. Just another reason not to use backticks!
But inside quotes or a heredoc, only the few listed characters are treated specially. Backslashes preceding all other regular characters will remain literal.
command + # output + # explanation:
Code:
echo \z # z #backslash interpreted. echo \\z # \z #2 backlashes become one. echo "\z" # \z #backslash not intepreted, not preceding a special character echo "\\z" # \z #2 backslashes become one. "\" precedes a special character, another '\'.
Code:
foo=bar cat <<EOF \z \\z "\z" "\\z" echo $foo echo \$foo $( echo $foo ) $( echo \$foo ) EOF #output: \z \z "\z" "\z" echo bar echo $foo bar $foo
As for this:
Code:
$ var=test $ echo `echo \$var` test
$(..), on the other hand, simply processes everything it contains as a regular command subshell. Just another reason not to use backticks!