Re: Bash-3.2 Official Patch 20
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 I offered to look at restoring a measure of backwards compatibility; try the attached patch. Chet *** ../bash-20080724/subst.c2008-08-01 22:20:31.0 -0400 --- subst.c 2008-08-17 20:15:52.0 -0400 *** *** 135,139 extern int last_command_exit_value, last_command_exit_signal; extern int subshell_environment; ! extern int subshell_level; extern int eof_encountered; extern int return_catch_flag, return_catch_value; --- 135,139 extern int last_command_exit_value, last_command_exit_signal; extern int subshell_environment; ! extern int subshell_level, parse_and_execute_level; extern int eof_encountered; extern int return_catch_flag, return_catch_value; *** *** 8092,8096 assigning_in_environment = 0; ! top_level_cleanup (); /* from sig.c */ jump_to_top_level (v); } --- 8092,8098 assigning_in_environment = 0; ! if (parse_and_execute_level == 0) ! top_level_cleanup (); /* from sig.c */ ! jump_to_top_level (v); } ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/
Re: Bash-3.2 Official Patch 20
Mike Frysinger wrote: 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) no error about UID being readonly, no echo HI I see. I'll take a look. 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 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.
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
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)
no output
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)
no output
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)
no error about UID being readonly, no echo HI
-mike
signature.asc
Description: This is a digitally signed message part.
