Jean Delvare dixit:
>A customer of ours has reported the following difference in behavior
>between mksh and ksh-93: unsetting a local variable causes mksh to
Do note that ksh93 has static scoping, unlike ALL other shells
which have hierarchical dynamic scoping comparable to other
programming languages.
The scoping model in ksh93 is fundamentally incompatible to
anything you know from anywhere else.
>destroy that local variable, so any further reference to its name will
>relate to the global variable by the same name. Example:
Yes, that is correct. You can then “local” it again to
recreate the local variable of said name.
>mksh will print 2, while ksh-93 will print 42. Note that bash will
>print 42 as well, and so does dash after adjusting the shell syntax so
>that dash understands it. So it seems that mksh handles this case
>differently from all other shells.
Interesting… so it seems that GNU bash and dash don’t really
unset it but only clean it.
>I see that one can use "unset foo[*]" in mksh to achieve the "unset
>foo" of other shells. I guess this is a side effect of the
You can? Hm, interesting… but makes sense.
>impossibility to preserve the variable attributes without preserving
>the variable itself. But this doesn't really help anyway, as this
>syntax is not portable.
if [[ $KSH_VERSION = *@(MIRBSD|LEGACY)\ KSH* ]]; then
function unset {
local __foo
for __foo in "$@"; do
eval "unset $__foo[*]"
done
}
fi
>So, is the behavior of unset on local variables a design decision, or
I believe the way mksh does it to be of the greatest benefit to
the user, although I never actively decided either way. It *is*
however what I’d expect when writing scripts.
(Note that pdksh also prints 2.)
bye,
//mirabilos
--
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
