On 9/3/25 9:47 PM, Zachary Santer wrote:
On Wed, Sep 3, 2025 at 4:05 PM Chet Ramey <[email protected]> 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 question is to whether to disallow it immediately or wait until there is an assignment.
The case without =value in the argument to declare is quite broken:
Well, it's inconsistent, which is what we're talking about here. Consider
declare -a a=('4')
declare -n b='a[0]'
declare -ni b
declare -p a b
b=4+3
$ 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
This is a straightforward application of the nameref rules. The problem
is that the arithmetic expansion is not helpful, since you can't use
namerefs to set the positional parameters. We can make that clearer.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
