UNIX for Advanced & Expert Users

The backquote concept is a bad design starting with mixing it in with the quoting concept. "Quoting" generally means "leave this stuff more or less untouched" until you get to backquotes which mean "run this command". That makes shell programming harder to teach and harder to learn. There are dozens of threads on this site where folks mixed up single quotes and backquotes. But no one has ever mixed up single quotes with $(... ). Running a program is a concept that should stand out as you read a shell script and it is easy to see for programs are being run due to $(...) while backquotes tend to hide program execution.

The shell has to parse its input to figure out what you want. Backquotes are recognized at the wrong time. By mixing this in with quoting, backquotes are recognized as the parameters for a command are being parsed. The $(...) is recognised much earlier. Consider a command like this:
command1 "this and that"
which produces a line of output and I want to embed that output into another string like this:
echo "the result is: $(command "this and that")"
The above syntax is guaranteed to work. But this backquote syntax is actually illegal:
echo "the result is: `command1 "this and that"`"
although modern shells often figure it out. Earlier shells would get mixed up and think the the first and second double quote are supposed to be a quoted string. To bypass that, you are supposed to protect interior double quotes with a backslash like this:
echo "the result is: `command1 \"this and that\"`"
and all shells must recognize this syntax. So when running a command inside backquotes a shell must translate \" to just " before running the command. But what if you actually want \" in your command? Well then you use \\" and now the shell must replace \\ by \ before running the command. This is why you had problems in the thread. Your \\ was being replaced by \ and you must double the number of backslashes to compensate. The fact that modern shells often figure out an expression that was not properly protected with backslashes actually raises the confusion level. The shell seems to be replacing \" with " just for the heck of it. This is why Vino was surprised above. Like many users, Vino has encountered behavior that seems surprising and inexplicable.

OK, right now you're thinking: "Well, what's wrong with few charming little ideosyncracies like these?" But where the backquote concept really gets complex is with nesting. With backquotes the same character serves to both start and end and command while the $(...) syntax has different element on each end. So if you try to imbed a backquoted command inside a backquoted command you must use \` and again the shell deletes the backslash. But while it is parsing the outer command, it also scans though the inner command replacing backslashes there as well. So with each level you must double the number of backslashes. Look at your example above. It took a sequence of 4 backslashes to get it to work. Now imbed that inside another backquoted command and you need 8 backslashes. Imbed that inside still another level and you're up to 16 backslashes. That's as far as I have ever taken it. Code up a few triple nested backquotes expressions and you'll see why I shy away from a quad. But some folks are made of sterner stuff. I've seen a few scripts where someone took it further. I'm not sure how many levels were involved though...I couldn't read the code.

Just an alternative

Code:

var=`echo "/home/abc/dec" | python -c "print raw_input().replace('/','\/')"`
echo $var

output:

Code:

\/home\/abc\/dec