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

[Chet Ramey]

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.

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