So I'm still getting caught up on this thread, but hasn't this issue been done
to death in previous threads? Back when I was examining bash's strange declare
-a, you were the very first person I found to notice its quasi-keyword behavior
10 years ago
(https://lists.gnu.org/archive/html/bug-bash/2004-09/msg00110.html). Perhaps
you didn't realize what this was doing at the time?
To me the biggest problem is what happens when you explicitly request a scalar
assignment. (I even specified a[1] to ensure it's not an "a vs. a[0]" issue.)
bash -c 'typeset -a a; b="(foo bar)"; typeset a[1]=$b; typeset -p a;
printf "<%s> " "${a[@]}"; echo'
declare -a a='([0]="foo" [1]="bar")'
<foo> <bar>
This doesn't fit with my understanding of how it should work. Otherwise I think
the way declare's arguments are interpreted based upon their form and current
set of attributes is pretty well understood, albeit undocumented.
I agree that ksh sometimes makes more sense. I'd add that although ksh's
typeset will never evaluate its non-literal parts of assignment arguments as
assignment syntax after the initial expansion, in ksh it isn't possible to
modify the _type_ of a variable after declaration to begin with, because ksh
has a confusing distinction between "types" and "attributes". Every time you
use a _different_ declaration command, you're wiping all attributes and
effectively unsetting then declaring a whole new variable, while attributes
remain mutable.
# In this case we're modifying attributes
$ ksh -c 'typeset -a x=(foo); print "${@x}"; typeset -r x=; print
"${@x}"'
typeset -a
typeset -r -a
# In this case we're modifying an attribute, then declaring a new
variable
# (and then implicitly modifying its attribute, though "${@a}" fails to
# report it correctly).
$ ksh -c 'typeset -a a=(foo); print "${@a}"; typeset -T A=(typeset x);
A a=(x=foo); print "${@a}"; a+=(x=bar); print "${@a}"; typeset -p a'
typeset -a A
A
A -a a=((x=foo) (x=bar))
If it were redesigned today there would surely be no attributes, only types.
--
Dan Douglas
