Re: Conditional Regexp matching problem in 3.2
Chet Ramey wrote: Kevin F. Quinn wrote: On Tue, 23 Jan 2007 16:55:02 -0500 Chet Ramey [EMAIL PROTECTED] wrote: I don't get this; I must be missing something. If I do, in bash-3.1: I get identical results with fully-patched versions of bash-3.1 and bash-3.2: $ /data/g2/tmp/portage/app-shells/bash-3.2_p9-r2/image/bin/bash -version GNU bash, version 3.2.9(1)-release (i686-pc-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. $ /data/g2/tmp/portage/app-shells/bash-3.2_p9-r2/image/bin/bash ~/x17 yes 1 yes 2 yes 3 yes 4 That's with bash-3.2 built with only the 001 through 009 patches applied (we have a few other local patches for various reasons, but I've built without them to be sure they're not affecting this). What's the (7) in the release number - does that refer to difference I might be missing? Strange. It succeeds on Mac OS X, Solaris, FreeBSD, and BSD/OS. Linux fails (Red Hat, FWIW). The glibc implementation of regcomp/regexec apparently does not allow backslashes to escape `ordinary' pattern characters. Posix leaves that behavior undefined; glibc seems to have made a different choice than most other implementations. It will be complicated to work around. It's little inconsistencies like this that induce developers to ship their own versions of library functions. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional Regexp matching problem in 3.2
[EMAIL PROTECTED] wrote:
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2
uname output: Linux kansas 2.4.18-26.7.x #1 Mon Feb 24 10:15:02 EST 2003 i686
unknown
Machine Type: i686-pc-linux-gnu
Bash Version: 3.2
Patch Level: 0
Release Status: release
Description:
A simple regexp match using =~ inside [[ ]] works on 3.0.16
and 3.1 versions of bash, but doesn't in 3.2.
In pre-3.2 versions, the script in Repeat-By (below)
produces one line of output: Dog 01 is Wiggles. In 3.2, the
regexp no longer matches, so it produces nothing.
Repeat-By:
# run this, eh?
DOG=Dog name - 01 - Wiggles
if [[ $DOG =~ ([[:alpha:][:blank:]]*)- ([[:digit:]]*) - (.*)$ ]]
then
echo Dog ${BASH_REMATCH[2]} is ${BASH_REMATCH[3]}
fi
One of the changes between bash-3.1 and bash-3.2 was to unify the handling
of the pattern in the `==' and `=~' conditional command operators. Pattern
characters on the rhs are quoted to represent themselves (remove their
special pattern meaning). This is how == has always worked. If you remove
the double quotes and use backslashes to escape the spaces in the pattern,
you will get the match you want.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong. No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional Regexp matching problem in 3.2
On Tue, 23 Jan 2007, Chet Ramey wrote:
[EMAIL PROTECTED] wrote:
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2
uname output: Linux kansas 2.4.18-26.7.x #1 Mon Feb 24 10:15:02 EST 2003 i686
unknown
Machine Type: i686-pc-linux-gnu
Bash Version: 3.2
Patch Level: 0
Release Status: release
Description:
A simple regexp match using =~ inside [[ ]] works on 3.0.16
and 3.1 versions of bash, but doesn't in 3.2.
In pre-3.2 versions, the script in Repeat-By (below)
produces one line of output: Dog 01 is Wiggles. In 3.2, the
regexp no longer matches, so it produces nothing.
Repeat-By:
# run this, eh?
DOG=Dog name - 01 - Wiggles
if [[ $DOG =~ ([[:alpha:][:blank:]]*)- ([[:digit:]]*) - (.*)$ ]]
then
echo Dog ${BASH_REMATCH[2]} is ${BASH_REMATCH[3]}
fi
One of the changes between bash-3.1 and bash-3.2 was to unify the handling
of the pattern in the `==' and `=~' conditional command operators. Pattern
characters on the rhs are quoted to represent themselves (remove their
special pattern meaning). This is how == has always worked. If you remove
the double quotes and use backslashes to escape the spaces in the pattern,
you will get the match you want.
Hi, Chet. Thanks for the explanation. I see the value in making ==
and =~ behave the same. However, we seem to have lost the ability to
use groupings to store results in BASH_REMATCH.
Escaping the spaces in the pattern doesn't work (though it does change
the error). I had actually tried that (in fact, I had tried every way
of escaping that pattern that I could think of) before sending in the
bashbug.
Using this pattern (spaces backslashed, double quotes removed):
if [[ $DOG =~ ([[:alpha:][:blank:]]*)-\ ([[:digit:]]*)\ -\ (.*)$ ]]
Yields this;
D:/tmp $ ~/src/bash-3.2/bash ./reduce.sh
Dog 01 is Wiggles
./reduce.sh: line 8: unexpected argument `(' to conditional binary
operator
./reduce.sh: line 8: syntax error near `(['
./reduce.sh: line 8: `if [[ $DOG =~ ([[:alpha:][:blank:]]*)-\
([[:digit:]]*)\ -\ (.*)$ ]]'
If I remove the grouping parens and leave the spaces escaped, like so:
if [[ $DOG =~ [[:alpha:][:blank:]]*-\ [[:digit:]]*\ -\ .*$ ]]
then I get a match, but $BASH_REMATCH is empty (since no groupings
were stored away):
D:/tmp $ ~/src/bash-3.2/bash ./reduce.sh
Dog 01 is Wiggles
Matched, anyway
Dog is
If I then also backslash-escape the parens, like so:
if [[ $DOG =~ \([[:alpha:][:blank:]]*\)-\ \([[:digit:]]*\)\ -\ \(.*\)$ ]]
then I no longer get the error, but the pattern doesn't match any more
at all.
D:/tmp $ ~/src/bash-3.2/bash ./reduce.sh
Dog 01 is Wiggles
So I still can't see how to get not just a match, but a match with
grouping, to work in 3.2 without putting the pattern into an
intermediate variable.
--
Ryan Waldron||| http://www.erebor.com|||[EMAIL PROTECTED]
The web goes ever, ever on, down from the site where it began...
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional Regexp matching problem in 3.2
On Tue, 23 Jan 2007 11:04:58 -0500 Chet Ramey [EMAIL PROTECTED] wrote: One of the changes between bash-3.1 and bash-3.2 was to unify the handling of the pattern in the `==' and `=~' conditional command operators. Pattern characters on the rhs are quoted to represent themselves (remove their special pattern meaning). This is how == has always worked. I don't get this; I must be missing something. If I do, in bash-3.1: $ V=alphabet $ [[ $V == alphabet ]] echo yes yes $ [[ $V == alphabet ]] echo yes yes $ [[ $V == 'alphabet' ]] echo yes yes $ [[ $V =~ alphabet ]] echo yes yes $ [[ $V =~ alphabet ]] echo yes yes $ [[ $V =~ 'alphabet' ]] echo yes yes $ yet if I try the same in 3.2: $ V=alphabet $ [[ $V == alphabet ]] echo yes yes $ [[ $V == alphabet ]] echo yes yes $ [[ $V == 'alphabet' ]] echo yes yes $ [[ $V =~ alphabet ]] echo yes yes $ [[ $V =~ alphabet ]] echo yes $ [[ $V =~ 'alphabet' ]] echo yes $ which to me looks like the two operators are not treating quotes the same way. -- Kevin F. Quinn signature.asc Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional Regexp matching problem in 3.2
I don't get this; I must be missing something. If I do, in bash-3.1: I get identical results with fully-patched versions of bash-3.1 and bash-3.2: $ cat x17 V=alphabet [[ $V == alphabet ]] echo yes 1 [[ $V == alphabet ]] echo yes 2 [[ $V == 'alphabet' ]] echo yes 3 [[ $V =~ alphabet ]] echo yes 4 [[ $V =~ alphabet ]] echo yes 5 [[ $V =~ 'alphabet' ]] echo yes 6 $ ../bash-3.2-patched/bash ./x17 yes 1 yes 2 yes 3 yes 4 yes 5 yes 6 $ ../bash-3.1-patched/bash ./x17 yes 1 yes 2 yes 3 yes 4 yes 5 yes 6 $ ../bash-3.2-patched/bash --version GNU bash, version 3.2.9(7)-release (powerpc-apple-darwin8.7.0) Copyright (C) 2005 Free Software Foundation, Inc. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional Regexp matching problem in 3.2
On Tue, 23 Jan 2007, Chet Ramey wrote: Bash Version: 3.2 Patch Level: 0 Release Status: release Install the patches. One (patch 3) deals with this issue. The following transcript shows the difference between the patched and unpatched versions of bash-3.2. That was it. Sorry about missing the patches. It's been a long time since I compiled bash directly, and I didn't realize that the 3.2.tgz version I downloaded wasn't fully patched already. Thanks! -- Ryan Waldron||| http://www.erebor.com|||[EMAIL PROTECTED] The web goes ever, ever on, down from the site where it began... ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional Regexp matching problem in 3.2
On Fri, 19 Jan 2007 00:56:03 -0600 (CST)
[EMAIL PROTECTED] wrote:
# run this, eh?
DOG=Dog name - 01 - Wiggles
if [[ $DOG =~ ([[:alpha:][:blank:]]*)- ([[:digit:]]*) -
(.*)$ ]] then
echo Dog ${BASH_REMATCH[2]} is ${BASH_REMATCH[3]}
fi
You can actually get it to work in bash 3.2, by writing:
if [[ $DOG =~ ([[:alpha:][:blank:]]*)-\ ([[:digit:]]*)\ -\ (.*)$ ]]
then
echo Unquoted Dog ${BASH_REMATCH[2]} is ${BASH_REMATCH[3]}
fi
however this fails in 3.1 - it'll work in 3.1 if you also escape the
brackets, but that then fails in 3.2. Which means the only way to
guarantee it is to write both, and check the bash version :/
Chet,
any comment on this issue? (see also my earlier mail from Sunday 14th,
http://lists.gnu.org/archive/html/bug-bash/2007-01/msg00035.html, and
Tim's bug at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220087)
At least to confirm/deny that it may be a real problem?
Thanks,
--
Kevin F. Quinn
signature.asc
Description: PGP signature
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
