[Top][All Lists]

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

Re: [BUG] persistently assigned variable cannot be unexported in POSIX m

From: Chet Ramey
Subject: Re: [BUG] persistently assigned variable cannot be unexported in POSIX mode
Date: Mon, 30 Apr 2018 15:12:04 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 4/30/18 2:57 PM, Martijn Dekker wrote:
> Op 27-04-18 om 22:16 schreef Chet Ramey:
>> On 4/25/18 10:51 PM, Martijn Dekker wrote:
>>> What I'm reporting here is a bug I discovered with unexporting a variable
>>> that is so exported while bash is in POSIX mode. It cannot be unexported
>>> using 'typeset +x' if you try to do that in a shell function.
>>> This works:
>>> $ bash -o posix -c 'foo=abc : ; typeset +x foo; env|grep ^foo='
>>> (no output, as expected: no longer exported)
>>> But this doesn't:
>>> $ bash -o posix -c 'fn() { foo=abc : ; typeset +x foo; env|grep ^foo=;
>>> }; fn'
>>> foo=abc
>> It seems like you're assuming that in posix mode, variable assignments that
>> precede special builtins executed in shell functions should create local
>> variables. Is that correct?
> No. The issue is:

It really is.

> 1. In POSIX mode, as ':' is a so-called special builtin, "foo=abc :" causes
> the assignment to 'foo' to persist past the ':' command, and 'foo' also
> remains exported. This is all POSIX-compliant.

Sure. But what does `persist' mean? Since it's Posix, it means create a
shell variable in the global context, since Posix doesn't have local
variables. This turns out to matter.

> 2. The bug is: 'declare +x' a.k.a. 'typeset +x' then fails to unexport the
> variable in the second version above. The variable remains exported past
> 'typeset +x foo', as proven by grepping the output of 'env'.

Now you've just created a local variable (typeset in a function creates
local variables, even in Posix mode) and made sure it doesn't have the
export attribute. You haven't given it a value, so it remains unset and
doesn't shadow the exported global you created in step 1.

> It shouldn't matter if the variable is local to the function or not, as
> everything is done in the same scope. 'declare +x' should clear the export
> flag as it is documented to do. In the second invocation quoted above, it
> doesn't.

Nope, if you want to use Posix and non-posix constructs, they end up in
different scopes.

> Having said that, I now cannot reproduce the issue in the 2018-04-27
> development snapshot... so thanks for fixing it anyhow :)

Bash is pretty careful not to create local variables when using builtins
that Posix standardizes: that's why `readonly' in a function creates a
global variable. This was another example of that: posix behavior when
implementing a posix-specified operation in posix mode. But I figured that
it would ultimately be less confusing to adopt your interpretation.

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

reply via email to

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