Bash can seem pretty random and weird at times, but most of what people see as quirks have very logical (if not very good) explanations behind them. This series of posts looks at some of them.
# Why does esc contain "x1B" instead of the escape char? esc=`printf \\x1B`
Short answer: “ requires another level of backslash escaping
To embed a backtick inside “, you escape it with a backslash. To embed a backslash, you escape it with another backslash. So `printf \\x1B` actually runs printf \x1B, and the shell interprets \x as a literal x with a superfluous escape. In other words, printf just sees “x1B”, and that’s what you get.
The problem grows exponentially as you try to nest ` `.
$(..) has distinct start and stop characters, so they can be used and nested without adding layers of backslashes. In this particular case you’d use esc=$'\x1B', and in general you could use esc=$(printf \\x1B).
# Why is newline empty instead of containing the line feed character?
newline=$(printf "\n")
echo "hello${newline}world"
Short answer: “ and $(..) strips trailing line feeds
$(..) and “ always strip trailing line feeds from command output. This is that special kind of magic that works so well you never think about it. echo “Hello $(whoami), how are you?” comes out as one line even though “whoami” (and basically all other commands) writes the username followed by a line feed.
This causes problems here because the output is only a single \n, i.e. the empty string followed by a trailing line feed. In this case, you’d again use newline=$'\n', but you could also have done newline=$(printf '\n'; printf x); newline=${newline#x} (append a x and then remove it), so that the line feeds in the output aren’t trailing.
# Bonus: Exercise for the reader # Try adding the appropriate quotes and # escapes to this quote normalization example normalized=`echo ``Go on'', he said | sed -e s/`/'/g`
The variable should contain ''Go on'', he said. Can you get it right on the first try?