[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: Martijn Dekker
Subject: Re: [BUG] persistently assigned variable cannot be unexported in POSIX mode
Date: Mon, 30 Apr 2018 20:57:08 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

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'

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:

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.

(I really wish it didn't remain exported, though. POSIX allows it, but doesn't mandate it; it's unspecified whether it remains exported or not. But it seems broken for it to remain exported. In fact I'm not sure why it's exported to begin with. As far as I know, there are no special builtins that run external binaries.)

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

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.

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

- Martijn

reply via email to

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