Disabling Variable Expansion in regular expressions.

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Java routine constructs Perl logical expression from user input to be used in another system. Java application calls a small Perl script to validate the expression. These logical expressions contain =~ type comparisons. The validation of the proper use of a dollar sign ($) inside the regular expression is being complicated by Perl variable expansion. The Perl validation routine does detect an improper use of a $ in a regular expression when the variable substitution doesn't find a defined variable, but it misses those cases when it does, i.e., $$, $1, $2, etc. For example this is an improper regular expression /^Money$1/ the dollar should have been escaped, but Perl thinks it's fine after substituting the command line variable into it.

I need a way to disable the variable expansion, while preserving the interpretation of regular expression metacharacters.

Comment on Disabling Variable Expansion in regular expressions.

Replies are listed 'Best First'.
Re: Disabling Variable Expansion in regular expressions. by Corion (Patriarch) on May 23, 2019 at 14:33 UTC
You don't show us how your Perl program is constructed, but the easiest approach would be: `my $re = '^Money$1'; 'teststring' =~ /$re/` [download] Also note that the regular expression is still valid as a regular expression, it just won't match much as `$` implies matching the end of the string/line.	[reply] [d/l] [select]
Re: Disabling Variable Expansion in regular expressions. by davido (Cardinal) on May 23, 2019 at 15:29 UTC
Without a small self-contained script demonstrating the circumstances that exhibit the problem you are having, the best advice I can give is to look at the following documentation: The Gory Details of Parsing Quoted Constructs quotemeta Regexp Quote Like Operators That will quickly get into the nuts and bolts of how to deal with string interpolation of variables. Dave	[reply]
Re: Disabling Variable Expansion in regular expressions. (single quotes as delimiters) by LanX (Saint) on May 23, 2019 at 16:11 UTC
> I need a way to disable the variable expansion, while preserving the interpretation of regular expression metacharacters. use single quotes as delimiter ... it's magic! `DB<17> $a= "xxx" DB<18> p 'xxx' =~ m/$a/ 1 DB<19> p 'xxx' =~ m'$a' DB<20>` [download] From perlre#The-Basics > Most times, the pattern is evaluated in double-quotish context, but it is possible to choose delimiters to force single-quotish, like `$foo =~ m'abc'` Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply] [d/l] [select]
Re^2: Disabling Variable Expansion in regular expressions. (single quotes as delimiters) by LanX (Saint) on May 23, 2019 at 16:28 UTC
hmm ... either it's buggy or I'm doing something wrong `$ perl print '$x' =~ m'$x' __END__ $` [download] EDIT: darn, the $ becomes an anchor for end-of-line `DB<8> use re 'debug'; '$a' =~ m'$a' Compiling REx "$a" Final program: 1: SEOL (2) 2: EXACT <a> (4) 4: END (0) anchored "a" at 0 (checking anchored) minlen 1` [download] unfortunate! Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply] [d/l] [select]
Re^3: Disabling Variable Expansion in regular expressions. (single quotes as delimiters) by Anonymous Monk on May 23, 2019 at 20:16 UTC
Rolf Sadly, my testing shows this is a valid indicator. Perl had no trouble with a pattern that had text past the end of string indicator. Though this is the mechanism I was looking for, it didn't produce the result I expected. Thank you so much for your help. It was exactly what I wanted, just not what I needed.	[reply]
Re^3: Disabling Variable Expansion in regular expressions. (single quotes as delimiters) by Anonymous Monk on May 23, 2019 at 18:57 UTC
Rolf, But that is precisely the outcome I am looking for. I want to detect the improper use of the $. This hard quoted form seems to be the answer I am looking for.	[reply]