On Mon, Sep 28, 2026 at 4:47 PM <[email protected]> wrote:
>
> So if -r or other attributes are involved as well, are users supposed to
> always turn one command into at least three? Because there are gotchas
> there too, like having to repeat -g otherwise -r applies to a new blank
> local (which doesn't make any sense) instead of the existing global.
I just want to point out the 'readonly' and 'export' builtins will
happily apply their respective attributes to a visible variable
declared at the scope of any function in the call stack as well as at
global scope. And using 'readonly' at least looks a bit more natural.
So then you've got
```
declare -A assoc
assoc=( [zero]=0 [one]=1 [two]=2 )
readonly assoc
```
and
```
main () {
declare -A assoc
set_that_forever
}
set_that_forever () {
assoc=( [zero]=0 [one]=1 [two]=2 )
readonly assoc
}
```
also works.
Still being an ideas guy, but the declare builtin could potentially
take some flag -- let's say -e, for "extant" -- specifying to find an
existing variable visible in any scope to add or remove whatever other
attributes as specified. And setting the variable in the same call
would still be setting the variable in its original scope.
While I'm looking at the devel branch manual:
> When -p is supplied without name arguments, declare will display the
> attributes and values of all variables having the attributes specified
> by the additional options.
I was thinking
$ declare -p +x
might show me the attributes and values of only the variables *not*
marked for export. It did not, in either 5.3.20(1)-release or the
current 5.4.0(1)-devel.
And looking at *that*, I can see that variables that bash sets for us
that are always going to be integers either will or will not have the
-i attribute, seemingly at random.
