[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[[ ... =~ ... ]] is broken when RHS is quoted
From: |
Alexis Huxley |
Subject: |
[[ ... =~ ... ]] is broken when RHS is quoted |
Date: |
Sun, 22 Jun 2008 11:07:03 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall
uname output: Linux lasagne 2.6.24-1-686 #1 SMP Thu May 8 02:16:39 UTC 2008
i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 3.2
Patch Level: 39
Release Status: release
Description:
[[ ... =~ ... ]] is broken when RHS is quoted
Repeat-By:
(This bug has been reported to Debian, but I did not come across a bug
report upstream, so here it is.)
# As described by OP, =~ has stopped working:
lasagne$ bash -c '[[ "apple" =~ "^(apple)" ]]; echo ${BASH_REMATCH[1]}'
<--- no output!
The bash man page says, in the section dealing with [[, that quote
removal
is performed but it seems not to be.
# Stripping the quotes from the RHS works:
lasagne$ bash -c '[[ "apple" =~ ^(apple) ]]; echo ${BASH_REMATCH[1]}'
apple
# Unfortunately if the RHS has spaces in then it doesn't work:
lasagne$ bash -c '[[ "apple banana" =~ ^(apple) banana ]]; echo
${BASH_REMATCH[1]}'
bash: -c: line 0: syntax error in conditional expression
bash: -c: line 0: syntax error near `banana'
bash: -c: line 0: `[[ "apple banana" =~ ^(apple) banana ]]; echo
${BASH_REMATCH[1]}'
# Unless those spaces are escaped:
lasagne$ bash -c '[[ "apple banana" =~ ^(apple)\ banana ]]; echo
${BASH_REMATCH[1]}'
apple
lasagne$
I'm a Debian user and this problem arose with a recent upgrade:
dpkg.log.1:2008-05-04 12:37:40 status unpacked bash 3.1dfsg-9
dpkg.log.1:2008-05-04 12:37:40 status unpacked bash 3.1dfsg-9
dpkg.log.1:2008-05-04 12:37:40 status unpacked bash 3.1dfsg-9
dpkg.log.1:2008-05-04 12:37:40 status half-configured bash 3.1dfsg-9
dpkg.log.1:2008-05-04 12:37:40 status installed bash 3.1dfsg-9
dpkg.log:2008-06-17 06:25:25 upgrade bash 3.1dfsg-9 3.2-4
dpkg.log:2008-06-17 06:25:25 status half-configured bash 3.1dfsg-9
dpkg.log:2008-06-17 06:25:25 status unpacked bash 3.1dfsg-9
dpkg.log:2008-06-17 06:25:25 status half-installed bash 3.1dfsg-9
dpkg.log:2008-06-17 06:25:26 status half-installed bash 3.1dfsg-9
dpkg.log:2008-06-17 06:25:26 status half-installed bash 3.1dfsg-9
dpkg.log:2008-06-17 06:25:26 status half-installed bash 3.1dfsg-9
dpkg.log:2008-06-17 06:25:26 status unpacked bash 3.2-4
dpkg.log:2008-06-17 06:25:26 status unpacked bash 3.2-4
dpkg.log:2008-06-17 06:25:32 configure bash 3.2-4 3.2-4
dpkg.log:2008-06-17 06:25:32 status unpacked bash 3.2-4
dpkg.log:2008-06-17 06:25:33 status unpacked bash 3.2-4
dpkg.log:2008-06-17 06:25:34 status unpacked bash 3.2-4
dpkg.log:2008-06-17 06:25:34 status unpacked bash 3.2-4
dpkg.log:2008-06-17 06:25:34 status unpacked bash 3.2-4
dpkg.log:2008-06-17 06:25:34 status half-configured bash 3.2-4
dpkg.log:2008-06-17 06:25:34 status installed bash 3.2-4
So I'm almost certain this is a bug introduced in bash 3.2. The COMPAT
and CHANGES files don't list anything that might mean this is a
change rather than a bug :-)
Let me know if I can be of further assistance.
Regards
Alexis Huxley
PS Debian's bashbug sends to debian site as well as bash's. I adjusted
the Debian address to be that of the already posted bug report, but
I'm not sure if bash's and Debian's bug report handlers will handle
the bash-style bug report correctly. Let's see what happens ...