[Top][All Lists]

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

Re: inconsistency with "readonly" and scope

From: dethrophes
Subject: Re: inconsistency with "readonly" and scope
Date: Thu, 12 Apr 2012 22:21:21 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1

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.


It took me a second to reproduce it, but here it is:

#! /bin/bash

    typeset v1=Hello

    echo "IN B:$v1"

    typeset -r v1=Goodbye

typeset -r v1=abc
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

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

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.

reply via email to

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