Re: "unset var" pops var off variable stack instead of unsetting it

[Chet Ramey]

On 3/17/17 5:51 PM, Stephane Chazelas wrote:

> Now, if that "split" functions is called from within a function
> that declares $IFS local like:
        [...]
> because after the "unset IFS", $IFS is not unset (which would
> result in the default splitting behaviour) but set to ":" as it
> was before "bar" ran "local IFS=."

This is how local variables work.  Setting a local variable shadows
any global with the same name; unsetting a local variable reveals the
global variable (or really, because bash has dynamic scoping, the value
at a previous scope) since there is no longer a local variable to shadow
it.

> 
> A simpler reproducer:
> 
> $ bash -c 'f()(unset a; echo "$a"); g(){ local a=1; f;}; a=0; g'
> 0
> 
> Or even with POSIX syntax:
> 
> $ bash -c 'f()(unset a; echo "$a"); a=0; a=1 eval f'
> 0

In this case, the unset unsets the variable provided in the builtin's
`environment'.  It's essentially the same thing.

> 
> A work around is to change the "split" function to:
> 
> split() (
>   local IFS
>   unset -v IFS  # default splitting
>   set -o noglob # disable glob
> 
>   set -- $1 # split+(no)glob
>   [ "$#" -eq 0 ] || printf '<%s>\n' "$@"
> )
> 
> For some reason, in that case (when "local" and "unset" are
> called in the same function context), unset does unset the
> variable.

There's special code in bash to preserve the locally-declared nature of
a variable if you use local and unset in the same function scope.  That's
been in bash forever (at least as far back as bash-2.0, which is when I
quit looking), for compatibility -- that's how ksh93 behaves -- and user
expectations.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/