On Wed, Sep 3, 2025 at 4:05 PM Chet Ramey <chet.ra...@case.edu> wrote:
>
> So the question is now whether to disallow `declare -in foo' (or
> `declare -in foo=bar') and make it a usage error, print a warning that
> it will be ineffective, or simply let it be ineffective, as it is now.
You already implemented this:
$ declare -in name=x[0]
bash: declare: x[0]: expands to invalid variable name for name reference
The case without =value in the argument to declare is quite broken:
$ declare -in foo
$ printf '%s\n' "${?}"
0
$ foo=bar
$ printf '%s\n' "${?}"
0
$ declare -p foo
declare -in foo="0"
$ printf '%s\n' "${?}"
0
$ foo=12
bash: `0': not a valid identifier
$ printf '%s\n' "${?}"
1
So the first assignment to a nameref variable that's already been
declared becomes the target and undergoes arithmetic expansion in this
case. Bash does not complain or even give an error status when bar
expands to 0, with that becoming the target of the nameref variable.
It's only when trying to assign to the nameref variable again that
bash detects a problem. The error message it gives doesn't make sense
unless you already know what's going on.
I support making both declare -in foo and declare -in foo=bar the same
usage error. I suggested
declare: integer attribute not valid for name reference
earlier in this thread.
I don't think there's any other case where the value part of declare
-n name=value gets expanded to something else than the literal
"value", so the error message that you implemented earlier may be
overly general.
