FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 01-26-2010, 01:57 PM
Roman Rakus
 
Default bash 4.1.2 and "broken" regular expression matching conditional operator (=~)

Hi all,
please take a look at bash faq section E - E14. Quoting:

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.


Please, take a look in your bash scripts and fix them.
RR
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-26-2010, 04:22 PM
Ville Skyttä
 
Default bash 4.1.2 and "broken" regular expression matching conditional operator (=~)

On Tuesday 26 January 2010, Roman Rakus wrote:
> Hi all,
> please take a look at bash faq section E - E14. Quoting:
>
> E14) Why does quoting the pattern argument to the regular expression
> matching conditional operator (=~) cause regexp matching to stop working?
[...]
> Please, take a look in your bash scripts and fix them.

Note also that in many cases it is possible to avoid using =~ altogether and
use plain == and simple globbing (possibly with multiple tests), and in even
more cases with extended globbing turned on. In addition to fewer portability
issues, globbing tends to be faster too.

If using extended globbing, just remember to reset extglob back to what it was
if your script is a sourced, not executed one, e.g. something like:

reset_extglob=$(shopt -p extglob)
shopt -s extglob
[[ "afoo" == *@(foo|bar|quux) ]] && echo hello
# ...
$reset_extglob

(We're not doing the reset in bash-completion yet, but eventually hopefully
will, or find another way to circumvent modifying users' shopt states.)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 04:10 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org