Go Back   openSUSE Forums > Archives > SF Archives > ARCHIVES - Programming & Scripting
Forums FAQ Members List Search Today's Posts Mark Forums Read


ARCHIVES - Programming & Scripting A place to discuss website design, programming, shell scripts, etc

 
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 03-Mar-2008, 10:14
jirka
Guest
 
Posts: n/a
Default

Hi,
I have program, name is t.sh :
Code:
#!/bin/bash

variable="This is a fine mess."

echo "$variable"

if [[ "$variable" =~ "T*fin*es*" ]]
then
**echo "match found"
fi
in openSUSE 10.1:
Code:
bash --version
GNU bash, version 3.1.17(1)-release (i586-suse-linux)
Copyright (C) 2005 Free Software Foundation, Inc.

./t.sh
This is a fine mess.
match found
This is OK, but in openSUSE 10.3:
Code:
bash --version
GNU bash, version 3.2.25(1)-release (i586-suse-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.

./t.sh
This is a fine mess.
NOT match found, this is bug?
  #2 (permalink)  
Old 06-Mar-2008, 21:40
suseforumsnet42
Guest
 
Posts: n/a
Default

Quote:
...
if [[ "$variable" =~ "T*fin*es*" ]]

... this is bug?
[/b]
No.

I noticed the above example comes from the Advanced Bash Guide at www.tldp.org. It probably should be updated to reflect Bash 3.2 and this changed behavior.

For your convenience, I snipped the entry in the GNU Bash FAQ that has reference to your question.

According to the FAQ at, http://www.gnu.org/software/bash/bash.html, which takes one to,
ftp://ftp.cwru.edu/pub/bash/FAQ:

E14) Why does quoting the pattern argument to the regular expression matching
conditional operator (=~) cause regexp matching to stop working?

In versions of bash prior to bash-3.2, the effect of quoting the regular
expression argument to the [[ command's =~ operator was not specified.
The practical effect was that double-quoting the pattern argument required
backslashes to quote special pattern characters, which interfered with the
backslash processing performed by double-quoted word expansion and was
inconsistent with how the == shell pattern matching operator treated
quoted characters.

In bash-3.2, the shell was changed to internally quote characters in single-
and double-quoted string arguments to the =~ operator, which suppresses the
special meaning of the characters special to regular expression processing
(`.', `[', `\', `(', `), `*', `+', `?', `{', `|', `^', and `$') and forces
them to be matched literally. This is consistent with how the `==' pattern
matching operator treats quoted portions of its pattern argument.

Since the treatment of quoted string arguments was changed, several issues
have arisen, chief among them the problem of white space in pattern arguments
and the differing treatment of quoted strings between bash-3.1 and bash-3.2.
Both problems may be solved by using a shell variable to hold the pattern.
Since word splitting is not performed when expanding shell variables in all
operands of the [[ command, this allows users to quote patterns as they wish
when assigning the variable, then expand the values to a single string that
may contain whitespace. The first problem may be solved by using backslashes
or any other quoting mechanism to escape the white space in the patterns.

Hope that helps.
 

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On




 

Search Engine Friendly URLs by vBSEO 3.3.0 RC2