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: > <OFEC551808.69D02C7F-ON8525729A.0045708D-8525729A.0046150 >[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.
