Re^5: hex code passed from command line is interpreted literally in substitution

Replies are listed 'Best First'.
Re^6: hex code passed from command line is interpreted literally in substitution by Allasso (Monk) on Mar 10, 2011 at 14:09 UTC
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.	[reply]
Re^7: hex code passed from command line is interpreted literally in substitution by ikegami (Patriarch) on Mar 10, 2011 at 19:50 UTC
So why doesn't it go ahead and interpolate it to the char 'A'? Because `$r` doesn't contain 'A'.	[reply] [d/l]
Re^7: hex code passed from command line is interpreted literally in substitution by Anonymous Monk on Mar 10, 2011 at 14:15 UTC
What?	[reply]
Re^8: hex code passed from command line is interpreted literally in substitution by Allasso (Monk) on Mar 10, 2011 at 14:32 UTC
`$rplc = "\\x41"; print $rplc; # prints the string \x41 $_ = "apples"; s@a@$rplc@; # variable containing the string \x41 used in RHS print; # - not interpolated to the char A $_ = "apples"; s@a@\x41@; # \x41 hardcoded into RHS print $_; # - interpolated to the char A __END__ outputs: \x41 \x41pples Apples` [download]	[reply] [d/l]
Re^9: hex code passed from command line is interpreted literally in substitution by Anonymous Monk on Mar 10, 2011 at 17:06 UTC
Re^10: hex code passed from command line is interpreted literally in substitution by Allasso (Monk) on Mar 10, 2011 at 17:22 UTC
Some notes below your chosen depth have not been shown here
Re^6: hex code passed from command line is interpreted literally in substitution by Allasso (Monk) on Mar 09, 2011 at 22:51 UTC
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	[reply]
Re^6: hex code passed from command line is interpreted literally in substitution by Allasso (Monk) on Mar 10, 2011 at 13:38 UTC
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"?	[reply] [d/l]
Re^7: hex code passed from command line is interpreted literally in substitution by Anonymous Monk on Mar 10, 2011 at 13:47 UTC
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	[reply]
Re^7: hex code passed from command line is interpreted literally in substitution by ikegami (Patriarch) on Mar 10, 2011 at 17:48 UTC
"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).	[reply] [d/l] [select]
Re^8: hex code passed from command line is interpreted literally in substitution by Allasso (Monk) on Mar 11, 2011 at 14:40 UTC
Okay, I think it is now starting to sink in. The most breaking revelation for me was understanding: '"',"\","x","4","1",'"' is Perl code. I was expecting string literals to be parsed as if they were perl code, which they are not. The subject still challenges my mind quite a bit, but some light is starting to come in. Thanks to all for much patience.	[reply]