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]
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
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:
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
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
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
