bug-bash
[Top][All Lists]
Advanced

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

Re: inconsistency with "readonly" and scope


From: Steven W. Orr
Subject: Re: inconsistency with "readonly" and scope
Date: Thu, 12 Apr 2012 16:38:29 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20

On 4/12/2012 4:21 PM, dethrophes wrote:
Am 12.04.2012 22:11, schrieb Steven W. Orr:
On 4/12/2012 2:16 PM, dethrophes wrote:
Am 12.04.2012 14:27, schrieb Chet Ramey:
On 4/11/12 4:12 PM, dethrophes wrote:

I've also noticed weird behavior with "declare -gr" the r sometimes seems
to override the g, but not specific to functions It seems to be specific
either to the source file or to the compound statement. I haven't been able
to figure out exactly whats going on there. I haven't been able to
reproduce it in a simple example. this is most readily noticeable with set
-o nounset
An example would help. The above is supposed to create a global readonly
variable. I suspect that you see the `global' as being `overridden'
because it's being created in a subshell environment.

Chet

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.

Does this help?




I only see the problem in large complex cases, I've tried to reproduce a
simple example a couple of times but without success.
no its not a subshell problem, I avoid subshells as much as possible.
also when I expereimented with the problem a couple of times I discovered the
following-
declare -g works
declare -gr doesn't work
my current workaround is I've just stopped using the readonly attribute which
works. or just stopped using declare altogether.
or do something like this
var=x
typeset -r var

I've also seen some strange behavior with
declare in a conditional sourced global context. it only seems to happen when
the code size is 10000s+ lines long.
I think this is exasperated by the fact that i source my files inside
conditional statements. the result is that I now even in a global context set
the global flag.

any ideas what could be causing it would help me try to figure out how to test
for it.

Sorry about the weak description but I've been working around it now for
months waiting for it to make sense and I'm no closer to figuring out whats
going on.
the problem is so erratic it has to be some sort of partial lost context or
something.

can you give me any tips on how to debug it if I can reproduce it again? is
their an easy way to track the validity of a variable?








I don't think it helps me but thanks for the try.
I would say zhats correct behavior. the code in the functions is only executed
when you call the functions. So the first executed readonly variable is
preserved.
Anyway my problem isn't with how readonly is preserved, its with how when I
set readonly the variable seems to have a limited context even if I declare it
explicitly global.



Ok, but do I have a point? I get your problem, but it seems like having a global variable that is allowed to be reinstantiated in an inner (albeit dynamic) scope should behave the same regardless of whether the global is readonly. Inside A, I don't get why I can't create a new variable whose failure (or success) depends on whether a previous outer scope variable exists as readonly.

Note that if v1 at the global scope is not readonly, the one in A *is* readonly, and the one in B is not, then there's no problem.

To me, this begs the question of whether all mainline code should be placed into a containing 'main' function so as to prevent this problem from occurring. Even if I do this, it still leaves me vulnerable to readonly variables that are sourced in before main is defined.

[I hope that didn't come off as a rant. ;-)]

--
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



reply via email to

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