{varname} for redirection does not work with arrays
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/home/lester/base/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2
uname output: Linux example.com 2.6.40.8-2.fc15.x86_64 #1 SMP Wed Oct 26
16:56:14 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.2
Patch Level: 10
Release Status: release
Description:
If {varname} is an assoc. array in a redirection the exec will fail
The [] should not be confused with pathname expansion just like ${}.
Repeat-By:
$ declare -A array
$ exec {array[key]}
Bug in bash regex: doesn't recognise the line start caret
Hi, There seems to be a bug in bash regex. It doesn't recognise the line start caret: --Commands: ONE="/fred" TWO="fred/" REGEX='^/' echo "$ONE $TWO $REGEX" [[ "$ONE" =~ "$REGEX" ]] && echo yes || echo no [[ "$TWO" =~ "$REGEX" ]] && echo yes || echo no --Result: /fred fred/ ^/ no no Not sure how to proceed. Thanks Graham (0779 321 1967)
[[ str =~ "^pattern" ]] no longer works
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic uname output: Linux dell1 2.6.32-71.el6.x86_64 #1 SMP Fri May 20 03:51:51 BST 2011 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.1 Patch Level: 2 Release Status: release Description: The [[ str =~ "^pattern" ]] operator no longer works correctly. "^" is treated as a literal instead of matching the beginning of the line. Repeat-By: [[ "-h" =~ '^-h' ]] ; echo $? Should return 0, but instead returns 1.
Re: Bug in bash regex: doesn't recognise the line start caret
On Fri, Nov 4, 2011 at 4:31 AM, Graham North wrote: > Hi, > > There seems to be a bug in bash regex. > > It doesn't recognise the line start caret: > > --Commands: > ONE="/fred" > TWO="fred/" > REGEX='^/' > echo "$ONE $TWO $REGEX" > [[ "$ONE" =~ "$REGEX" ]] && echo yes || echo no > [[ "$TWO" =~ "$REGEX" ]] && echo yes || echo no > > > --Result: > /fred fred/ ^/ > no > no > > Not sure how to proceed. > > Thanks > > Graham (0779 321 1967) > > > > The regex must not be quoted. [[ $one =~ $regex ]]. Also, as an aside, don't use all-caps variable names. Those should only be used for environment and internal shell variables (as in internal to bash).
Re: [[ str =~ "^pattern" ]] no longer works
On 11/04/2011 09:09 AM, flong@dell1.localdomain wrote: Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic uname output: Linux dell1 2.6.32-71.el6.x86_64 #1 SMP Fri May 20 03:51:51 BST 2011 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.1 Patch Level: 2 Release Status: release Description: The [[ str =~ "^pattern" ]] operator no longer works correctly. "^" is treated as a literal instead of matching the beginning of the line. Repeat-By: [[ "-h" =~ '^-h' ]] ; echo $? Should return 0, but instead returns 1. It was bug in previous versions of bash in fedora and RHEL. This behavior is correct now. RR
Re: [[ str =~ "^pattern" ]] no longer works
On Fri, Nov 04, 2011 at 05:30:52PM +0100, Roman Rakus wrote: > On 11/04/2011 09:09 AM, flong@dell1.localdomain wrote: > > [[ "-h" =~ '^-h' ]] ; echo $? > > Should return 0, but instead returns 1. > > > It was bug in previous versions of bash in fedora and RHEL. > This behavior is correct now. Expanding this slightly: when a character in the operand on the right hand side of the =~ operator is quoted, that character no longer retains its Regular Expression meaning, and instead becomes a string literal. This also applies to quoted substitutions, as in [[ $a =~ "$b" ]]. If you want the value of $b to be treated as an ERE, don't quote it. [[ "-h" =~ '^-h' ]] compares the string -h to the string ^-h and of course they are not equal. [[ "-h" =~ ^-h ]] does what you expected. re='^-h' [[ "-h" =~ $re ]] is the preferred way to write the code. It's even written in the manual this way.
Re: {varname} for redirection does not work with arrays
You're missing a dollar sign.
bash-completion between do and done
Hi, Current, bash doesn't do command completion between do and done (for loop). I'm wondering if this feature can be added. -- Regards, Peng
Re: bash-completion between do and done
Peng Yu wrote: > Current, bash doesn't do command completion between do and done (for loop). > I'm wondering if this feature can be added. Of course bash does do command completion between do and done. Can you give an exact example test case? On what version of bash? Bob
