Re: Defining variable as local -r defines variable outside the function in some cases

[Chet Ramey]

On 2/13/23 10:33 AM, Voldemar Lazarev via Bug reports for the GNU Bourne 
Again SHell wrote:

> Bash Version: 5.2
> Patch Level: 15
> Release Status: release
>
> Description:
>      When a function has a variable (e.g. "X") defined as local and read-only ("local -r") and the 
> function is called with variable of same name ("X") specified before function name (see the 
> "Repeat-By" section), the variable becomes defined outside the function.

This has kind of a circuitous history. There always needed to be code to
propagate temporary environment variables supplied to function invocations
back to the previous scope in posix mode, since POSIX required that for
years and years. The variables were exported during function execution to
satisfy the "available to the function and its children" semantics.

As part of an effort to increase implementation compatibility in order to
standardize local variables, I changed bash so that local variables and the
temporary environment share the same namespace, so changes to a local
variable in a function that has the same name as a variable in the
temporary environment are reflected to that function's descendents. This
discussion among shell developers happened in late 2001.

(We could never agree on the dynamic/static scoping issue, so that stalled
the standardization effort, and people are still arguing about that today.)

This came in back in January, 2002 and first appeared in bash-2.05b, but
still only in posix mode.

Finally, we get to April, 2013. The "recommended changes" part of

https://www.austingroupbugs.net/view.php?id=654

says:

"For issue 8, if implementors agree, I suggest something like this:
                [...]

  - Exported: The temporary variable binding has the export attribute
    set (until cleared by the function or special built-in utility, if
    it chooses to do so).

  - Modification makes the binding persist: Any modification to the
    variable binding (setting the export attribute even if it is
    already set, clearing the export attribute even if it is already
    clear, setting the readonly attribute even if it is already set,
    setting the value even if it is already set to the same value,
    unsetting the variable even if it is already unset) by a function
    or special built-in utility causes the binding (with whatever
    attributes it has after modification) to persist after the
    function or special built-in utility returns."

So the attribute changes get propagated back to the previous scope, but
this doesn't consider local variables, since POSIX doesn't consider local
variables. However, unifying the local variable namespace and the
temporary environment means you end up operating on the same variable.

The current bash behavior (dating from bash-4.3 in 2013) is compatible with
ksh93. However, it might be time to change this again, since the ultimate
resolution of issue 654 resulted in POSIX removing the special handling of
temporary variable assignments preceding function calls (it's all
completely unspecified in the upcoming revision).

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/