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: Robert Elz
Subject: Re: It is possible to remove the readonly attribute from {BASH, SHELL}OPTS
Date: Fri, 23 Feb 2024 20:13:28 +0700

    Date:        Fri, 23 Feb 2024 09:15:09 +1000
    From:        Martin D Kealey <martin@kurahaupo.gen.nz>
    Message-ID:  
<CAN_U6MWTx-hXB8=+4u+MLJvfgSHVBu=daQXPP5aPWyftKr911g@mail.gmail.com>

  | Yes, that's exactly the point, to *avoid* dynamic scoping. I want the
  | equivalent of Perl's "my", rather than Perl's "local".

Lexical scoping does not, that is, cannot, work with the shell
language as it is defined, if you want that you need to go and
invent a whole new language.

As it is thare are too many places in sh where correct operation
requires access to specific vars, which makes no sense (ie: would
not work as intended with lexically scoped local vars) - consider
PATH CDPATH PWD OPTIND OPTARG REPLY (for shells that have it)
and try to explain how they can be made to work as intended if
made local, with lexical scoping.

Regardless of how much people have tried to attempt to impose
a more programming language model on sh vars, it simply does
not work.   sh was designed to operate using an entirely global
namespace - the best way to think of 'local' is 'save the value
and attributes of this var as they are now, and restore them when
the current function invocation terminates' - and absolutely no
more than that.  All operations continue to use a single global
namespace, and because of that, everything simply works as it
should without issues.  Deviate even a little and there get to be
all kinds of problems.

  | new code can avoid the craziness that comes from "everything is global,

crazy or not, that is the sh model.  If you don't like it, use
something different -- tclsh (or with graphics added, wish) is much
more rigorous, and also much less friendly interactively.

  | even when we claim it's local" and "unset can even mess with the poor
  | protection afforded by 'local'".

I'm guessing you mean bash's bizarre unset definition wrt locals.
I consider that to just be a bug.  Unsetting a 'local' variable
should be identical to unsetting a global, as that is what
actually happens (should happen).  That there is a saved copy that
will be restored later is irrelevant.

kre



reply via email to

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