Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout'
-DNON_INTERACTIVE_LOGIN_SHELLS
uname output: Linux t420 5.15.55-2-lts #1 SMP Fri, 22 Jul 2022
23:29:06 +0000 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
`bash' does not let `unset' fully undeclare local variables. (so that
they can be used later as `local' variables without needing to
redeclare them I assume.)
bash-5.1$ x=abc; declare -p x; unset -v x; declare -p x
declare -- x="abc"
bash: declare: x: not found
bash-5.1$ a () { local x=abc; local -p x; unset -v x; local -p x ;}
bash-5.1$ a
declare -- x="abc"
declare -- x
However, other functions are allowed to delete those variables:
bash-5.1$ a () { local x=abc; b; local -p x ;}
bash-5.1$ b () { unset -v x ;}
bash-5.1$ a
bash: local: x: not found
This enables defininng a "really_unset" function like so:
really_unset () { unset "$@" ;}
Which may be useful I guess.
But I think allowing functions to unset local variables from other
functions defeats the whole purpose of having that `unset'
behaviour. This enables `local' variable to unexpectedly become global
after a function is called.
Fix:
I think calling `unset -v x' (where `x' is a local variable not in the
current scope) should behave as if it was called in the scope of `x',
so `x' should remain declared in that scope with no attributes and no
value.
It may be nice to also add a "force" option for `unset' that makes it
actually unset the variable if it is `local'. Since this could be
useful in some cases and it won't be possible after the behaviour is
changed.
