wrong behaviour when unsetting/setting some variables

[Christoph Anton Mitterer <calestyo@xxxxxxxxxxxx>]

Hey.

Forwarding this from my report (for the records) at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064874


POSIX describes[0] unset to:
> unset values and attributes of variables and functions

While the exact detials are perhaps a bit unclear (see the discussion
at [1], I
think it is rather clear that unset, on a variable that has no readonly
attribute,
shall case the variable/value binding AND any attributes to be unset.


This works as expected in dash for most variables, but not some, e.g.:
$ env -i dash
$ export
export PWD='/home/calestyo'
$ export MAIL
$ export
export MAIL
export PWD='/home/calestyo'
$ unset -v MAIL
$ export
export MAIL
export PWD='/home/calestyo'
$ 

Same for MAILPATH and PATH, which made me believe it's perhaps an issue
in `changemail` and `changepath` as given in the struct `varinit` in
src/var.c.
But it also happens with IFS, PS1, PS2 and PS4, which have no function
listed there.
OTOH, it doesn’t happen with ATTY, TERM, LINENO and HISTSIZE.

The consequence of that is at least, that one has no chance to fully
unset these
variables, and even if they loose their value, they’ll be exported to
executed
commands, possibly altering their behaviour.


I think a similar problem exists when using local variables, but there
it's even
worse as it seems to affect any variable names:
```
f()
{
	export
	echo
	
	local FOO=v
	export FOO
	export
	echo
	
	unset -v FOO
	export
}

f
```
gives:
```
export PWD='/home/calestyo'

export FOO='v'
export PWD='/home/calestyo'

export FOO
export PWD='/home/calestyo'

```
and presumaby that `FOO` would then be exported to executed commands.


Cheers,
Chris.


[0]
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#unset
[1] https://austingroupbugs.net/view.php?id=1806