[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BUG] 'unset' fails silently under specific conditions
From: |
Martijn Dekker |
Subject: |
Re: [BUG] 'unset' fails silently under specific conditions |
Date: |
Wed, 2 May 2018 15:07:42 +0100 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
Op 02-05-18 om 02:20 schreef Chet Ramey:
You complained that `typeset +x' didn't `unexport' a variable. The reason > is
that the variable assignment preceding the special builtin caused a
variable to be created at the global scope, and the `typeset' resulted in
a local variable being created.
I still can't see how that is relevant here: 'typeset'/'declare' is not
involved in the current issue. But then, neither is 'unset'. It does
appear that the current issue is not what I thought it was.
Instead, in POSIX mode, it looks like a variable assignment preceding a
special builtin may create a variable at a function-local scope without
'typeset'/'declare' being involved at all. But not always.
Let's see if I'm getting it right this time. In the following:
set -o posix
f() { foo=bar : ; }
f
the command 'foo=bar :'
1. makes the assignment 'foo=bar' survive the ':' command;
2. gives 'foo' a global scope;
3. permanently exports the global variable 'foo'.
However, in the following:
set -o posix
f() { foo=bar; foo=baz : ; }
f
the plain assignment 'foo=bar' creates an ordinary global variable named
'foo' with value 'bar', and then the command 'foo=bar :'
1. makes the assignment 'foo=baz' survive the ':' command, but by
creating *another* 'foo' instead of overwriting the first;
2. gives that other 'foo' a function-local scope;
3. exports the local variable 'foo' for the duration of its existence.
My testing confirms that this is what appears to happen, and I think
it's a bug, because (1) POSIX has no notion of variables with a
function-local scope; (2) even if it did, no command was issued that
should make the variable local to the function; and (3) the behaviour in
the second example is inconsistent with that in the first.
I think 'foo=baz :' should act the same in the second example as
'foo=bar :' does in the first, i.e.: if there is already a variable by
that name it should be overwritten, just like with any normal shell
assignment.
- M.
- [BUG] 'unset' fails silently under specific conditions, Martijn Dekker, 2018/05/01
- Re: [BUG] 'unset' fails silently under specific conditions, Martijn Dekker, 2018/05/01
- Re: [BUG] 'unset' fails silently under specific conditions, Chet Ramey, 2018/05/01
- Re: [BUG] 'unset' fails silently under specific conditions, Martijn Dekker, 2018/05/01
- Re: [BUG] 'unset' fails silently under specific conditions, Chet Ramey, 2018/05/01
- Re: [BUG] 'unset' fails silently under specific conditions,
Martijn Dekker <=
- Re: [BUG] 'unset' fails silently under specific conditions, Greg Wooledge, 2018/05/02
- Re: [BUG] 'unset' fails silently under specific conditions, Greg Wooledge, 2018/05/02
- Re: [BUG] 'unset' fails silently under specific conditions, Martijn Dekker, 2018/05/02
- Re: [BUG] 'unset' fails silently under specific conditions, Chet Ramey, 2018/05/02
Re: [BUG] 'unset' fails silently under specific conditions, Robert Elz, 2018/05/01