bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: It is possible to remove the readonly attribute from {BASH, SHELL}OP


From: Martin D Kealey
Subject: Re: It is possible to remove the readonly attribute from {BASH, SHELL}OPTS
Date: Tue, 20 Feb 2024 19:11:03 +1000

On Sat, 17 Feb 2024 at 02:32, Chet Ramey <chet.ramey@case.edu> wrote:

> Let's say we take the approach of restricting attribute changes on readonly
> variables to export/trace/local.
>
> Should it be an error to attempt to set other attributes (it already is
> with nameref), or should declare silently ignore it?
>

I would prefer to make "local" behave as much as possible like a true
lexically scoped declaration in "regular" languages.

Much as I hate the effect on backwards compatibility, I hate the current
situation even more: it's not possible to write a re-usable general-purpose
utility function because the function has to avoid overriding outer
variables that might differ in their attributes from what the function
needs. Arrays and read-only are particularly problematic.

So yes please, I'd like "local" to push a new variable definition that
inherits nothing from any outer one: not name-ref, not read-only, not array
(of any kind), not assignment modifiers (integer, upper-case, lower-case),
and above all, not any previous values.

Ideally each function invocation would have its own variable namespace,
only using the global namespace as a fall-back, but that creates
complications with exported variables, so let's take baby steps to get
there.

Maybe this would be twisting 'local' too much, and it warrants creating a
new keyword such as 'var'?

-Martin


reply via email to

[Prev in Thread] Current Thread [Next in Thread]