Re: Bash-3.1.17 gets lost looking for end of string in certain contexts

2006-05-02 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Richard on 5/1/2006 5:46 PM:
> 
> 602   status=`echo 'beriberi'| { ${GREP} -E -e '().*\1' >/dev/null 2>&1 ; 
> echo $?; }`

I could not reproduce this - are you sure you reported it correctly?

$ foo=`echo 'beriberi'| { grep -E -e '().*\1' >/dev/null 2>&1 ;
> echo $?; }`
$ echo $foo
0
$ echo `echo 'beriberi'| { grep -E -e '().*\1' >/dev/null 2>&1 ;
> echo $?; }`
0
$ echo $BASH_VERSION
3.1.17(6)-release

However, there are still some known issues with `` command substitution
parsing in bash-3.1 that have been previously reported, such as
http://lists.gnu.org/archive/html/bug-bash/2006-03/msg00039.html.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEV01v84KuGfSFAYARAmSWAJ9Rx4cdXJ4v19QtndJkV5JsKb6s0gCgt6c2
AxNqtFlldig+XZv4YqKGLCA=
=l1nt
-END PGP SIGNATURE-


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash


Re: Bash-3.1.17 gets lost looking for end of string in certain contexts

2006-05-02 Thread Eric Blake
[Please keep replies on the list, so that others that encounter the
same problem may see it in the archives, and so that you can
get comments from more than just me.]

> On Tuesday 02 May 2006 09:15, you wrote:
> > According to Richard on 5/1/2006 5:46 PM:
> > > 602   status=`echo 'beriberi'| { ${GREP} -E -e '().*\1' 
> > > >/dev/null 2>&1
> > > ; echo $?; }`
> >
> > I could not reproduce this - are you sure you reported it correctly?
> 
>   I was afraid that would happen :/
>   If you cannot reproduce then something else most likely is the culprit; 
> will 
> have to investigate further in order to circumscribe the situation. And yes, 
> unfortunately my report is correct.
> 
>   At any rate, let me give you the underlying actual running environment 
> at the 
> time of said "bug":
> 
>   running in chroot, using gcc-3.4.6 and glibc-2.3.6; bash was compiled 
> in 
> that 
> same environment as grep; grep bombed during testsuite check; all other 
> packages that were compiled in same 'batch', which includes bash, grep, gcc 
> and glibc, completed flawlessly.
> 
> >
> > $ foo=`echo 'beriberi'| { grep -E -e '().*\1' >/dev/null 2>&1 ;
> >
> > > echo $?; }`
> >
> > $ echo $foo
> > 0
> > $ echo `echo 'beriberi'| { grep -E -e '().*\1' >/dev/null 2>&1 ;
> >
> > > echo $?; }`
> >
> > 0
> > $ echo $BASH_VERSION
> > 3.1.17(6)-release
> 
>Noted. Shall revert asap either cancelling the report or refining the 
> data 
> fpr analysis with evidence from further probing.
> 
> >
> > However, there are still some known issues with `` command substitution
> > parsing in bash-3.1 that have been previously reported, such as
> > http://lists.gnu.org/archive/html/bug-bash/2006-03/msg00039.html.
> 
>   Noted as well. Had already experienced change of reaction in one of my 
> scripts, but I interpreted then the difference as being a bug of the previous 
> version, and that the current way seemed more logical. Now I realise, from 
> the e-mail, what was the reason for the change in attitude on bash's part 
> and, to a certain extent, justified my neutral reaction to the finding.
> 
>   Tks for prompt reply.
>   Richard



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash