Date: Fri, 15 Jul 2022 16:13:40 +0000 (UTC)
From: Robert Stoll <robert.st...@tegonal.com>
Message-ID: <1549965963.26496.1657901620717.javamail.zim...@tegonal.com>
| Unfortunately I have never built bash on my own and it would probably
| take me too much time to do it.
It probably wouldn't, fetch the tarball, unpack it, ./configure && make
and you're done (after a short wait).
But that's only useful if a newer version fixes some problem, or if you
want to make changes of your own - the latter can certainly take time.
| Thus, I am writing to this e-mail in the hope that someone more
| experienced can try to reproduce it with the latest version.
There is no need, what you're seeing isn't a bug. readonly variables
cannot be made local, the bash man page even says so ...
The return status is 0 unless local
is used outside a function, an invalid name is supplied, or name
is a readonly variable.
The "readonly in a function can be made local in another function" thing
most likely is a bug - but (as I have said before, and will keep on saying)
bash's view of what a local variable should be is simply weird. It isn't
true lexical scoping, like Korn was (IMO, inadvisedly) trying to achieve
in ksh, and it isn't simple and sane like other shells, just a mess.
One last comment - you probably shouldn't be using read only variables
at all, they're a rather special use case, and attempting to make a local
read only variable is weird in itself, but with the same name as some other
read only variable, is simply perverse. Read only vars are best left for
applications which need something they can depend on not being able to be
changed (by anything - which is why making one local is not supposed to work)
in which case they tend to have names you're not likely to trip over by
accident when making a local var in a function.
kre
