bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: Re: Bash-3.1.17 gets lost looking for end of string in certain contexts
Date: Wed, 03 May 2006 02:51:22 +0000

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]