On 4/12/12 4:11 PM, Steven W. Orr wrote:
> It took me a second to reproduce it, but here it is:
>
> ----------------------
> #! /bin/bash
>
> A()
> {
> typeset v1=Hello
>
> B
> echo "IN B:$v1"
> }
>
> B()
> {
> typeset -r v1=Goodbye
>
> :
> }
> typeset -r v1=abc
> A
> echo "v1:$v1"
> --------------------------
>
> This is 4.0.35(1).
>
> The v1 that's set to abc is the global one.
> A defines a local copy that's not readonly and B defines one that is. When
> I run it I get:
>
> 950 > ./foo.sh
> ./foo.sh: line 5: typeset: v1: readonly variable
> ./foo.sh: line 13: typeset: v1: readonly variable
> IN B:abc
> v1:abc
>
> This means that the typeset failed is both A and B and the references in
> the routines fell back to the global instance of v1.
This is intended. Bash doesn't allow a local copy of a variable to
override a readonly global one. This can be a potential security hole,
especially if the readonly variable is exported, assuming that the
person/script/agent that set the variable readonly really didn't intend
for it to be modified for a reason.
However, the code allows a local variable to override a different
function's readonly local variable with the reasoning that the security
hole is not as great. If you don't like the global behavior, you can work
around it by having a function declare all your variables as local and
relying on dynamic scoping to treat them as essentially global.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
