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