Re: Bash-3.2 Official Patch 20
On Friday 24 August 2007, Chet Ramey wrote: >BASH PATCH REPORT >= > > Bash-Release: 3.2 > Patch-ID: bash32-020 > > Bug-Reported-by: Ian A Watson <[EMAIL PROTECTED]> > Bug-Reference-ID: > [EMAIL PROTECTED]> Bug-Reference-URL: > > Bug-Description: > > In some cases of error processing, a jump back to the top-level processing > loop from a builtin command would leave the shell in an inconsistent > state. this appears to break handling of read only variables in source statements consider: $ cat test.sh #!/bin/bash unset MOO COW cat << EOF > source-test.sh MOO=1 UID=1 COW=1 EOF source ./source-test.sh echo WANT: MOO=1 COW=1 echo HAVE: MOO=$MOO COW=$COW when run with bash versions before 3.2_p20, we see: WANT: MOO=1 COW=1 HAVE: MOO=1 COW=1 when run with bash versions starting with 3.2_p20, we see: WANT: MOO=1 COW=1 HAVE: MOO=1 COW= in the case of Gentoo, we have some code that saves/reloads the entire environment in between invocations and we dont bother picking out the readonly variables ... so the env does not fully get reloaded as a readonly variable appears in the `set` output rather quickly :( -mike signature.asc Description: This is a digitally signed message part.
Re: Bash-3.2 Official Patch 20
On Saturday 25 August 2007, Mike Frysinger wrote: > On Friday 24 August 2007, Chet Ramey wrote: > > BASH PATCH REPORT > > = > > > > Bash-Release: 3.2 > > Patch-ID: bash32-020 > > > > Bug-Reported-by:Ian A Watson <[EMAIL PROTECTED]> > > Bug-Reference-ID:>50 [EMAIL PROTECTED]> Bug-Reference-URL: > > > > Bug-Description: > > > > In some cases of error processing, a jump back to the top-level > > processing loop from a builtin command would leave the shell in an > > inconsistent state. > > this appears to break handling of read only variables in source statements this may also just be a bug fix, i just want confirmation before we go changing things :) -mike signature.asc Description: This is a digitally signed message part.
Re: Bash-3.2 Official Patch 20
Mike Frysinger wrote: >> Bug-Description: >>> >>> In some cases of error processing, a jump back to the top-level >>> processing loop from a builtin command would leave the shell in an >>> inconsistent state. >> this appears to break handling of read only variables in source statements > > this may also just be a bug fix, i just want confirmation before we go > changing things :) I've considered it, and concluded that the post-patch 20 behavior is the right thing. If a variable assignment error occurs during execution of a builtin, it should cause the builtin to return with a non-failure status (unless you're running a non-interactive shell in posix mode, in which case Posix says the whole shell should exit). I do see what Gentoo is trying to do, and I'll try to devise a workaround to accommodate both needs. 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/
Re: Bash-3.2 Official Patch 20
On Saturday 25 August 2007, Chet Ramey wrote:
> Mike Frysinger wrote:
> >> Bug-Description:
> >>> In some cases of error processing, a jump back to the top-level
> >>> processing loop from a builtin command would leave the shell in an
> >>> inconsistent state.
> >>
> >> this appears to break handling of read only variables in source
> >> statements
> >
> > this may also just be a bug fix, i just want confirmation before we go
> > changing things :)
>
> I've considered it, and concluded that the post-patch 20 behavior is the
> right thing. If a variable assignment error occurs during execution of
> a builtin, it should cause the builtin to return with a non-failure status
> (unless you're running a non-interactive shell in posix mode, in which
> case Posix says the whole shell should exit).
>
> I do see what Gentoo is trying to do, and I'll try to devise a workaround
> to accommodate both needs.
thanks
a side note ... if you change any of BASH_{ARGC,ARGV,LINENO,SOURCE} before
setting a readonly variable, bash will not spit out the error message about
the variable being readonly ...
(UID=1)
-bash: UID: readonly variable
(BASH_ARGC= UID=1)
this regression seems to have appeared between the last bash-2 and the first
bash-3 ...
-mike
signature.asc
Description: This is a digitally signed message part.
Re: Bash-3.2 Official Patch 20
Mike Frysinger wrote:
> a side note ... if you change any of BASH_{ARGC,ARGV,LINENO,SOURCE} before
> setting a readonly variable, bash will not spit out the error message about
> the variable being readonly ...
> (UID=1)
> -bash: UID: readonly variable
> (BASH_ARGC= UID=1)
>
> this regression seems to have appeared between the last bash-2 and the first
> bash-3 ...
They're not readonly variables. The shell doesn't allow them to be unset,
but you can assign new (even nonsense) values.
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/
Re: Bash-3.2 Official Patch 20
On Saturday 25 August 2007, Chet Ramey wrote:
> Mike Frysinger wrote:
> > a side note ... if you change any of BASH_{ARGC,ARGV,LINENO,SOURCE}
> > before setting a readonly variable, bash will not spit out the error
> > message about the variable being readonly ...
> > (UID=1)
> > -bash: UID: readonly variable
> > (BASH_ARGC= UID=1)
> >
> > this regression seems to have appeared between the last bash-2 and the
> > first bash-3 ...
>
> They're not readonly variables. The shell doesn't allow them to be unset,
> but you can assign new (even nonsense) values.
what i meant was that for some reason, i didnt get the readonly error after
modifying one of those four values, but the script stopped parsing at the
same spot since it was a readonly var ...
(UID=1)
-bash: UID: readonly variable
(BASH_ARGV=""; UID=1; echo HI)
-mike
signature.asc
Description: This is a digitally signed message part.
