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



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

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

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?
      $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
        I don't understand; that is the original question, which has been answered