Re: typeset -r prevents local variable of same name.

[Chet Ramey]

On 2/17/11 10:23 PM, Eric Blake wrote:
> On 02/17/2011 08:18 PM, Chet Ramey wrote:
>> On 2/17/11 10:12 PM, Eric Blake wrote:
>>> On 02/17/2011 07:48 PM, Chet Ramey wrote:
>>>> Consider a quick, contrived example: an administrator writes a shell
>>>> package (library, set of functions, whatever) that includes, among
>>>> other things, ways to make sure that some other package is invoked with
>>>> a particular set of arguments and environment.  He does this in part by
>>>> declaring some variables readonly.  Programs invoked by this package
>>>> change their behavior depending on the value of environment variables,
>>>> so it's important to the correct operation of this script that the
>>>> variables don't change.  It should be harder to cirvumvent this, possibly
>>>> creating a security hole, than just declaring a shell function with a
>>>> local variable that then calls a public function that expects the variable
>>>> to have some other value.
>>>
>>> Ah, so we're back to the debate of static vs. dynamic scoping.  
>>
>> Not really.  The readonly variables could be declared at the global
>> scope.  Overriding a global variable can cause the same problem.
> 
> With static scoping the ONLY place that sees the local variable override
> is the intermediate shell function.  If the intermediate function calls
> a public function, that public function will still see the (readonly)
> global variable. (Think C or ksh local variables.)

I'm not talking about public functions.  I'm talking about a shadowed
copy of an exported variable that gets passed to child processes in the
same function where it's declared.  If static scoping doesn't allow that,
local variables become much less useful.

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/