bash 2.0 string matching

Question

I'm on GNU bash, version 2.05b.0(1)-release (2002). I'd like to determine whether the value of $1 is a path in one of those /path/*.log rules in, say, /etc/logrotate.conf. It's not my box so I can't upgrade it.

Edit: my real goal is given /path/actual.log answer whether it is already governed by logrotate or if all the current rules miss it. I wonder then if my script should just run logrotate -d /etc/logrotate.conf and see if /path/actual.log is in the output. This seems simpler and covers all the cases as opposed to this other approach.

But I still want to know how to approach string matching in Bash 2.0 in general...

• the line itself can start with some white space or none
• it's not a match if it is in a commented line (comments are lines where the first non white space char is #)
• there can be one or more paths on the same line to the left of $1
  
  • like if $1 is /my/path/*.log and the line in question is
    • /other/path*.log /yet/another.log /my/path/*.log {
• there can be one or more paths to the right as well
• the line itself can end with { and even more white space or not
• paths can be contained in double-quotes or not
• it can be assumed that the file is a valid logrotate conf file.

I have something that seems to work in Bash 4 but not in Bash 2.05. Where can I go to read what Bash 2.0 supports? How would this matching be checked in Bash 2.0?

Answer 1

You can find a terse bash changelog here.

You'll see that =~, the regex-matching operator, didn't get introduced until version 3.0.

Thus, your best bet is to use a utility to perform the regex matching for you; e.g.:

if grep -Eq '<your-extended-regex>' <<<"$1"; then ...

---

grep -Eq '<your-extended-regex>' <<<"$1":

• IS like [[ $1 =~ <your-extended-regex> ]] in Bash 3.0+ in that its exit code indicates whether the literal value of $1 matches the extended regex <your-extended-regex>
  • Note that Bash 3.1 changed the interpretation of the RHS to treat quoted (sub)strings as literals.
  • Also note that grep -E may support a slightly different regular-expression dialect.
• is NOT like it in that the grep solution cannot return capture groups; by contrast, Bash 3.0+ provides the overall match and capture groups via special array variable ${BASH_REMATCH[@]}.