[SOLVED] Bash Version 3.1 to 3.2 and Later --- Inconsistent Pattern Matching

mrm5102 · 07-16-2012, 03:53 PM

Hello All,

I created a script that starts/stops a program on a couple different servers.

The server I wrote the script on has Bash Version 3.2.51(1)-release, and there are
a couple of different servers where the version is 3.1... and possibly some after version 3.

The problem I'm running into is this line below:

Code:

	if [[ ! $@ =~ start|stop|restart|status|help ]]
	 then
		echo "Error(1): No option given for start|stop|restart|status"
		exit 1
	fi

Now this line works just fine on the server I wrote it on, but on another server I tested it on with
Bash Version 3.1.17 I get this error for that line:

Code:

./test_script: line 51: syntax error in conditional expression: unexpected token `|'
./test_script: line 51: syntax error near `|s'
./test_script: line 51: `	if [[ ! $@ =~ start|stop|restart|status|help ]]'

So if I change the code on the older Bash Version Server, and I surround the pattern in either single or double quotes, the script executes without a hitch. But if I add that to the one with the newer Bash Version it reads the pattern as a literal string instead of a pattern. I've also tried surrounding the pattern in backslashes "/". Which works on the newer Bash Version, but again, not on the older one...?

Does anyone know of anyway I can express this where it would be compatible on both versions and possible even newer versions of Bash?

Any thoughts would be much appreciated.

Thanks in Advance,
Matt

Kenhelm · 07-16-2012, 05:36 PM

Try putting the pattern into a variable.

Code:

pattern='start|stop|restart|status|help'
if [[ ! $@ =~ $pattern ]]

Bash pitfall number 35
http://mywiki.wooledge.org/BashPitfa...e_RE.27_.5D.5D

Quote:

35. if [[ $foo =~ 'some RE' ]]
The quotes around the right-hand side of the =~ operator cause it to become a string, rather than a RegularExpression. If you want to use a long or complicated regular expression and avoid lots of backslash escaping, put it in a variable:

re='some RE'
if [[ $foo =~ $re ]]

This also works around the difference in how =~ works across different versions of bash. Using a variable avoids some nasty and subtle problems.

Advanced Bash-Scripting Guide 37.2.2. Bash, version 3.2
http://www.tldp.org/LDP/abs/html/bas...#REGEXMATCHREF

Quote:

The =~ Regular Expression match operator no longer requires quoting of the pattern within [[ ... ]].
In fact, quoting in this context is not advisable as it may cause regex evaluation to fail. Chet Ramey states in the Bash FAQ that quoting explicitly disables regex evaluation. See also the Ubuntu Bug List and Wikinerds on Bash syntax.

Setting shopt -s compat31 in a script causes reversion to the original behavior.

grail · 07-16-2012, 09:05 PM

I agree with the variable option for anything other than a simple text comparison. It is interesting that the link provided by Kenhelm also states:

Quote:

# NOTE: As of version 3.2 of Bash, expression to match no longer quoted.

Which would imply that you could still quote if needed, but the quote by Kenhelm is further down the page so I am guessing should really be used as an addendum.

patrick295767 · 07-16-2012, 11:54 PM

Quote:

Originally Posted by mrm5102

Hello All,

I created a script that starts/stops a program on a couple different servers.

The server I wrote the script on has Bash Version 3.2.51(1)-release, and there are
a couple of different servers where the version is 3.1... and possibly some after version 3.

The problem I'm running into is this line below:

Code:

	if [[ ! $@ =~ start|stop|restart|status|help ]]
	 then
		echo "Error(1): No option given for start|stop|restart|status"
		exit 1
	fi

Now this line works just fine on the server I wrote it on, but on another server I tested it on with
Bash Version 3.1.17 I get this error for that line:

Code:

./test_script: line 51: syntax error in conditional expression: unexpected token `|'
./test_script: line 51: syntax error near `|s'
./test_script: line 51: `	if [[ ! $@ =~ start|stop|restart|status|help ]]'

So if I change the code on the older Bash Version Server, and I surround the pattern in either single or double quotes, the script executes without a hitch. But if I add that to the one with the newer Bash Version it reads the pattern as a literal string instead of a pattern. I've also tried surrounding the pattern in backslashes "/". Which works on the newer Bash Version, but again, not on the older one...?

Does anyone know of anyway I can express this where it would be compatible on both versions and possible even newer versions of Bash?

Any thoughts would be much appreciated.

Thanks in Advance,
Matt

WHich distro is it?

I hope that it is not debian testing, because, if it is a bug I am not so sure we get it fixed on time for the stable release

grail · 07-17-2012, 03:04 AM

I doubt any copy of Debian is still languishing back with bash 2.05

(could be wrong of course)

gnashley · 07-17-2012, 03:25 AM

Code:

 case $@ in
  start|stop|restart|status|help) : ;;
  *) echo "Error(1): No option given for start|stop|restart|status"
  exit 1
  ;;
esac

That should work for any bash version from 2 to 4.

mrm5102 · 07-17-2012, 08:27 AM

Hey Guys, thanks for all your replies!

Ahh Yes putting it in a variable.... I'll give that a go and see what happens, don't know why I didn't think of that.

Also, for those who asked about the distro. Most of the servers I am going to put this on are SLES 11.1 and some back as far as Version 10.1...
The one server that I first tried this on was a "SuSE Linux Enterprise Server v10.2" with Bash version of 3.1.17(1).

I'm gona give your suggestions a try and post back my results.
Thanks again for ALL your suggestions.

Thanks,
Matt

mrm5102 · 07-17-2012, 08:45 AM

Hey... Thanks everybody, That worked perfectly!

I tried it on 3 different servers with 3 different Bash version from 3.1 to 4.1.10 and all seems gooood...

Is putting patterns into variables a "more" preferred way to do that then how I was doing it in my OP?

Thanks Again,
Matt

grail · 07-17-2012, 12:36 PM

The variable just allows you to update away from the test and also seems to work more often than not if the match is more complex than a straight string match.

silendo · 07-17-2012, 12:47 PM

Code:

case $@ in
  start|stop|restart|status|help) : ;;
  *) echo "Error(1): No option given for start|stop|restart|status"
  exit 1
  ;;
esac

gnashley: i agree with you

mrm5102 · 07-17-2012, 02:00 PM

Hey grail, thanks for the reply...

Thank you for the explanation.

Thanks Again,
Matt