Re: inconsistency with "readonly" and scope

[Chet Ramey]

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    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/