Path: csiph.com!goblin2!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: worley@alum.mit.edu (Dale R. Worley)
Newsgroups: gnu.bash.bug
Subject: Re: Local variable names clash with global read-only variable names.
Date: Thu, 30 Apr 2020 22:43:53 -0400
Lines: 25
Approved: bug-bash@gnu.org
Message-ID: <mailman.1733.1588301045.3066.bug-bash@gnu.org>
References: <be8dd110-c269-be88-b14c-8359e4c547f5@case.edu> (chet.ramey@case.edu) <87wo5wgys6.fsf@hobgoblin.ariadne.com>
NNTP-Posting-Host: lists.gnu.org
Cc: andrej@podzimek.org, bug-bash@gnu.org, chet.ramey@case.edu
To: chet.ramey@case.edu
Envelope-to: bug-bash@gnu.org
In-Reply-To: <be8dd110-c269-be88-b14c-8359e4c547f5@case.edu> (chet.ramey@case.edu)
Received-SPF: permerror client-ip=2001:558:fe21:29:69:252:207:34; envelope-from=worley@alum.mit.edu; helo=resqmta-ch2-02v.sys.comcast.net
Precedence: list
Xref: csiph.com gnu.bash.bug:16260

>>>     f() { local x=a; }
>>>     declare -r x
>>>     f  # bash: local: x: readonly variable
>>>
>>>   This^^^ should not fail; it hinders reusability of shell functions and makes
>>>   them context-dependent.

It's "natural" to think that a variable that is local to a function
should be independent of however it is declared globally.  The problem
is that bash local variables aren't lexically scoped -- when you enter
the function, the variable acquires the new value, but any function that
is called by this function sees the new value, even if that function
wasn't declared inside the function that declared the variable local.
So if a local declaration could override a readonly declaration, the new
value could be seen by code unrelated the function that did the
override.

This is a common issue in language design.  The Perl language originally
only had "local" declarations that behaved the same way as bash local
declarations.  But the above behavior got to be so much of a problem for
large programs that Perl added a separate lexically-scoped local
declaration.

Dale