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

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";
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"?
  • Comment on Re^6: hex code passed from command line is interpreted literally in substitution
  • Download Code

Replies are listed 'Best First'.
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

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."'").""

    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.
    $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.

    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).

      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.