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

[Steven W. Orr]

On 2/16/2011 11:08 PM, Clark J. Wang wrote:
> On Thu, Feb 17, 2011 at 11:13 AM, Chet Ramey<chet.ramey@case.edu>  wrote:
>
> > > If I declare a variable at the top scope using -r, it will prevent me
> > > from declaring a local copy in a subroutine. This problem happens in
> > > this version of bash as well as in bash4 under Fedora 14.
> >
> > This is intentional.  A variable is declared readonly for a reason, and
> > readonly variables may not be assigned to.  I don't believe that you
> > should be able to use a function to circumvent this.
> >
> > That makes little sense to me. I don't see any disadvantages if a local var
> is allowed to use the same name as a global readonly var. And with current
> bash behavior we may see var name collisions even with the local keyword.
>
> > Chet

I'd like to agree with Clark. I agree that a variable is declared readonly for 
a purpose, but the act of declaring any variable in a subroutine must 
explicitly mean that it is a different instance than any other instance.

If I declare an outer scope variable as an array or an integer, why should 
that be treated any differently than if it's declared as readonly? (I do 
understand that a type like int or container declaration like array is 
different from a readonly attribute, but either way, it's just a part of the 
implementation of a scoped symbol table.) Internally, we either have scoped 
symbol tables or we don't. Worst case scenario, it would be easy (whatever 
that means) to write a bash lint function that would warn about a global 
readonly variable that is shadowed by a variable of the same name in a function.

Just for context, I'm at a place that has maybe 100K lines of hack'n'wack bash 
code that was written by the usual crowd of people who only mostly knew 
minimal Bourne shell where everything is a self contained monolithic 
structure. I'm trying to refactor this nightmare so that we can create common 
libraries of subroutines, common libraries of global variables for project 
specific purposes, an some of those globals need to be readonly. When people 
write subroutines and declare a local variable, they should not need to go 
through a clearing house to see if a name is safe to use locally. If they 
*don't* declare it, then (and only then) they should expect to bump into any 
predefined global variable. The idea is that not declaring a variable in a 
function is the same as creating a global.

Have a swayed your thinking?

And BTW Chet, you're high on my list of people who have made a non-readonly 
global impact on the world. :-)

--
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net