[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: inconsistency with "readonly" and scope

From: Chet Ramey
Subject: Re: inconsistency with "readonly" and scope
Date: Thu, 12 Apr 2012 21:05:46 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

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.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]