Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #16261

Re: Local variable names clash with global read-only variable names.

From Greg Wooledge <wooledg@eeg.ccf.org>
Newsgroups gnu.bash.bug
Subject Re: Local variable names clash with global read-only variable names.
Date 2020-05-01 07:37 -0400
Message-ID <mailman.1756.1588333100.3066.bug-bash@gnu.org> (permalink)
References <be8dd110-c269-be88-b14c-8359e4c547f5@case.edu> <87wo5wgys6.fsf@hobgoblin.ariadne.com> <20200501113700.GC17864@eeg.ccf.org>

Show all headers | View raw


On Thu, Apr 30, 2020 at 10:43:53PM -0400, Dale R. Worley wrote:
> 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.

Perl is a programming language.  It makes sense that perl would evolve
in a way that makes it more useful for writing programs.

Bash, on the other hand, is first and foremost a *shell*.  It's designed
to act as an interface for executing commands, either interactively, or
in a script.  Its use as a programming language is a distant second goal.

In the context of a shell, variables have *power* and *meaning*.  If a
variable is declared readonly, it's because someone wants it to remain
unchanged.  Consider what happens when someone changes PATH or HOME.

Readonly variables become immutable, because changing them would break
something.  Someone decided that, and *made* the variable readonly, and
they had some reason to do that.  You're not allowed to circumvent
that restriction.

It has nothing to do with language design.

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: Local variable names clash with global read-only variable names. Greg Wooledge <wooledg@eeg.ccf.org> - 2020-05-01 07:37 -0400

csiph-web