Bug 672714

Summary: ambiguous meaning of $ after =~
Product: [Fedora] Fedora Reporter: Curtis Doty <curtis>
Component: bashAssignee: Roman Rakus <rrakus>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 14CC: rrakus, tsmetana
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-26 14:21:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Curtis Doty 2011-01-25 23:53:29 UTC 
Related to bug 652211...

This expression worked on f<13, but was b0rk by removal of the cond-rmatch patch:

( echo $BASH_VERSION ; b=foo ; [[ $b-42 =~ "^$b-[0-9][0-9]\$" ]] && echo right || echo wrong )
4.0.38(1)-release
right

( echo $BASH_VERSION ; b=foo ; [[ $b-42 =~ "^$b-[0-9][0-9]\$" ]] && echo right || echo wrong )
4.1.7(1)-release
wrong

So, apparently the fix is to remove the quotes. But the only way to get the trailing $ to properly match EOL is to also not escape it.

( b=foo ; [[ $b-42 =~ ^$b-[0-9][0-9]\$ ]] && echo right || echo wrong )
wrong

Which still leaves some ambiguity over what purpose the $ symbol has in that context.

( b=foo ; [[ $b-42 =~ ^$b-[0-9][0-9]$ ]] && echo right || echo wrong )
right
Comment 1 Roman Rakus 2011-01-26 14:21:05 UTC 
It's not. It is parsed as expected. `$' is followed by `b' so it's variable expansion. The last `$' is followed by space ` ' so it's processed as single `$' and in Pattern Matching means match the EOL. So, no ambiguity.