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