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}"

        recho $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    c...@case.edu    http://cnswww.cns.cwru.edu/~chet/

Reply via email to