[Top][All Lists]

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

Re: Cleaning up bash releases at first directory level

From: Koichi Murase
Subject: Re: Cleaning up bash releases at first directory level
Date: Thu, 23 Mar 2023 07:44:43 +0900

,2023年3月21日(火) 22:40 Chet Ramey <>:
> On 3/20/23 11:18 PM, Koichi Murase wrote:
> > Otherwise, impractical and
> > problematic changes only requested by a single insistent person, like
> > `localvar_unset', would easily enter the codebase.
> Are you sure you mean `localvar_unset'?

Yes, `localvar_unset' (and `localvar_inherit'), but I have to admit
that I do not know the detailed history of the debate. The event I
remember is [1], which made me decide to actively participate in
discussions of bug-bash. Before this event, I had only submitted a few
patches and had been just reading discussions in the list without
participating in any discussions, so I probably don't remember
discussions before it very well.


I know that the code of `localvar_unset' has existed before but had
not been exposed as a shell option `shopt -s localvar_unset' until
that discussion. I'm not sure about the past discussions in
bug-bash/help-bash, but elsewhere, I observed many people who don't
even know what is dynamic scoping regard it as a bug and insist that
dynamic scoping is a ``design bug'' even after telling them about the
dynamic scoping. I wouldn't like to let such people break the dynamic
scoping model of Bash halfway.

In the 2018-03 discussion, there was only one person (kre) who
requested the behavior. I think making requests is a good thing to
possibly improve the design but at the same time think we can (and
should) discuss if the change would cause practical problems. The
interest of kre is consistently the portable scripts, and the request
is clearly not from a practical point of view for Bash scripting he is
working on but from an aesthetic one. Even from the aesthetic point of
view, the desired behavior depends on the person as we can see in the
diversity of the behavior among the shells with dynamic scoping: yash,
mksh, and osh (oilshell) (and bash until 1995 according to the
discussion), removes the placeholder of a local variable with `unset'
while zsh and posh makes the state of the local variable unset. I
actually think the behavior of yash and mksh (which is opposite to
localvar_unset) is more reasonable considering the dynamic scoping,
and I do not think the behavior of the local variables should be
always identical to the global variables (but I must admit that I
haven't followed the discussion made in 1995).

Anyway, as mentioned in [1], practically the most important thing was
backward compatibility for the scripts of the past 23 years
(1995..2018). `shopt -s localvar_unset' affects the behavior of all
the existing libraries and frameworks [note 1]. The behavior change of
« unset -v var » doesn't cause problems in an independent script that
has full control of the shell options, but the frameworks and
libraries need to work under an arbitrary set of shell options
provided by the main environment (or make explicit restrictions on the
shell options of the main environment).

[note 1] I think it wouldn't have caused a problem if the new ``static
unset'' were introduced as a distinct option such as « unset -s var ».

We sometimes need to introduce backward-incompatible changes if the
old behavior causes problems or the new behavior is much better than
the old one, but I doubt that localvar_unset has a practical benefit.
For the portable scripts, as far as yash and mksh behave in the way of
purely dynamic scoping, localvar_unset doesn't make it possible to
write the portable scripts, For the real use cases, it seems to be
hard to find a script that uses localvar_unset in the real Bash
scripting. From curiosity, I searched "localvar_unset" in GitHub. I
can find 28 cases of localvar_unset used in shell scripts [2]:


where 18 cases are workarounds for localvar_unset (unsetting
localvar_unset by `shopt -u localvar_unset' and restoring it if
necessary), 3 cases are just in code comments, and 1 case is used to
read the current value of the setting. There are 6 cases that actually
sets localvar_unset. One is Modernish which tries to provide a
consistent behavior among different POSIX shells, (which is incomplete
particularly for `unset' because of yash and mksh). Two of them sets
localvar_unset in a bash program, but I'm not sure if the option has
actually the effect because they do not seem to unset any variables in
the script. The other three are `bashrc's that set localvar_unset in a
long list of `shopt' (where I'm not sure if it is included for the
real necessity). We cannot find actual combinations of
`localvar_unset' and `unset var' in Bash in GitHub.


reply via email to

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