On 7/23/15 10:57 AM, isabella parakiss wrote:
> On 7/23/15, Greg Wooledge <wool...@eeg.ccf.org> wrote:
>> People who use "readonly" are generally doing so in the context of a
>> "restricted shell" (yes, commence laughter) or other situation where
>> that specific variable is the key to unlocking something that the
>> administrator does not want the user to unlock. The entity who used
>> "readonly" is presumed to want that variable to remain unchanged, forever.
>
> On 7/23/15, Stephane Chazelas <stephane.chaze...@gmail.com> wrote:
>> 2015-07-23 01:12:01 +0200, isabella parakiss:
>> What that means is that with this kind of dynamic scoping,
>> "readonly" is not very helpful. I don't remember ever using it.
>
> You guys are assuming that I am the one who uses readonly.
> I'm not, *bash* is.
This is an excellent time to point out that it's to everyone's advantage
to be as complete as possible when describing a problem on the list,
rather than revealing additional details one at a time.
There's no way anyone would have guessed that you were encountering this
with BASH_REMATCH; the most likely possibility was that you were trying to
override a variable you had declared readonly.
Yes, BASH_REMATCH is special. It's not present by default, and it is
destroyed and reconstituted fresh every time you use the =~ operator to
[[, since it's only supposed to exist if something matched. I suppose
there's no real reason to make it readonly other than that there's no real
reason to write to it, and =~ is the only thing that can modify it.
Removing the restriction on local copies of readonly variables wouldn't do
a thing to change the BASH_REMATCH semantics, though it would allow scripts
to unset it. We would need a different discussion about how you'd like
BASH_REMATCH to work.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
