Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #14079 > unrolled thread

Re: [BUG] 'unset' fails silently under specific conditions

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [BUG] 'unset' fails silently under specific conditions Martijn Dekker <martijn@inlv.org> - 2018-05-02 15:07 +0100

#14079 — Re: [BUG] 'unset' fails silently under specific conditions

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.

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web