Correct. Perl string literal «"\\x41"» is the same as bash string literal «'\x41'». Both produce the string "\","x","4","1". Print $r if you don't believe me.

I guess I am having difficulty with the interpolation thing. I'll keep working on it though.

ps, I replied to bart below, that is also a reply to you. thanks.

reply

Okay, I guess I can see what you are saying when you say they are "not different", if I word it more like, "both expressions evaluate to the same thing when one is placed inside quotes in perl code, and the other is passed as an arg from the command line." Each string, "\", "x", "4", "1", and "\", "\", "x", "4", "1", are obviously treated in different ways in order to produce the same result. That is the difference I was asking about. I guess the answer is, one is interpolated, and the other isn't.

I am wondering this: why can't I then just do:

$r = "$r";
[download]

Why doesn't putting the string, which is now, "\", "x", "4", "1", inside the quotes not cause perl to interpolate the string to the character with the value of 41 hex, just as if I wrote, "\x41"?

Why does't....

Because people have enough trouble learning/understanding regular interpolation, that double-interpolation would cause their heads to explode. Even the esoteric programming language b****fuck doesn't have double-interpolation.

See String::Interpolate

"both expressions evaluate to the same thing when one is placed inside quotes in perl code

No, I meant "both expressions evaluate top the same thing given the language in which they are placed (perl and bash)". It's just an irrelevant coincidence that perl and bash both understand «'\x41'» to mean the same thing.

That is the difference I was asking about.

The entire point of my post is that it wasn't the relevant difference. The difference is whether "\" is in the literal or if it's in the string that's interpolated. Literals care about "\". Interpolation, concatenation, print, join, etc, etc, etc, etc don't care about "\".

why can't I then just do: $r = "$r";

Well, if you used your way of doing things, that would be an infinite loop.

Why doesn't putting the string, which is now, "\", "x", "4", "1", inside the quotes

"\","x","4","1" is not inside the quotes. "$","r" is. '"',"\","x","4","1",'"' is Perl code. "\","x","4","1" is a different sequence of characters, and you never gave it to the parser.

So your question boils a down to why does interpolation means insert into the string ("".$r."") instead of

"".eval('"'.$r."'").""
[download]

That would make interpolation completely useless and extremely dangerous.

$r = $cgi->param('r');  # If he provides <<".system("rm -rf /").">>,
$r = "You said $r";     #    the user deletes the server's hard drive.
[download]

$r = $cgi->param('r');  # If he provides <<$r>>,
$r = "You said $r";     #    the user causes an infinite loop.
                        #    He could bring down the server in a sec.
[download]

If you want to execute Perl code, you first have to have valid Perl code ('"',"\","x","4","1",'"' instead of "\","x","4","1"), and you need to call the Perl parser explicitly (eval , require, etc).

Also, why is the behaviour different when a variable containing the string "\", "x", "4", "1" is placed inside the RHS (substitutes the literal string, \x41), than if the string is hardcoded in (substitutes the character 'A'? Obviously, some interpolation is going on, otherwise you would get the string, "$", "r". So why doesn't it go ahead and interpolate it to the char 'A'?

Then there is my original question, about why it does it in the LHS. But maybe if I understand the above question, I will better understand the answer to this one. Obviously their nature is different, ie, one evaluates regex, and the other doesn't. Perhaps I am having some confusion about whether, \xNN is a regex or not. It is interpolated as a character in the RHS, (when hardcoded in), but other regexes are interpreted literally.

So why doesn't it go ahead and interpolate it to the char 'A'?

Because $r doesn't contain 'A'.

What?