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

[Chet Ramey]

On 3/17/17 8:21 PM, Stephane Chazelas wrote:

> I don't expect the need to have to add "local var" in
> 
> (
>    unset -v var
>    echo "${var-OK}"
> )
> 
> would be obvious to many people beside you though.

Try the following:

function foo
{
(
        unset -v IFS
        recho "${IFS-unset}"

        foo='a:b:c:d'
        recho $foo
)
}

IFS=':|'
foo
echo after IFS = "$IFS"

Bash and ksh93 echo '<unset>', '<a:b:c:d>', and ':|'.


> People writing function libraries meant to be used by several
> POSIX-like shells need to change their code to:
> 
> split() (
>   [ -z "$BASH_VERSION" ] || local IFS # WA for bash bug^Wmisfeature
>   unset -v IFS
>   set -f 
>   split+glob $1
> )
> 
> if they want them to be reliable in bash.

Well, there's the fact that you've left the realm of standardization when
you start talking about local variables, so "Posix-like" doesn't have
much meaning.

> 
>> The problem is the non-obvious nature of unset's interaction with scope,
> 
> the main problem to me is an unset command that doesn't unset.

So you don't like dynamic scoping.  This is not new.

> As shown in my original post, there's also a POSIX conformance
> issue.

Yeah, it looks like there is differing behavior that has to do with the
"special builtin" nature of eval and unset.  In Posix, these two statements
are essentially equivalent:

a=1 eval unset a
a=1; eval unset a

I am not a fan of the special builtin behavior rules.

-- 
``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/