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

[Robert Elz]

    Date:        Wed, 15 Feb 2023 11:57:45 -0500
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <8295e33a-da67-676c-66cb-9593871ce9dc@case.edu>

  | 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).

That's because functions and commands should look the same to the code
that calls them, if one does

        VAR=foo cmd ...

it should not suddenly behave differently if someone later decides
to make a function

        cmd() { command cmd -opt "$@"; }

What happens to VAR should be the same in both cases.  Nothing else
makes any sense (the original description for what happened for
functions was just because of the stupid buggy ksh implementation of
them, which didn't do this the only rational way).

For now it needs to be unspecified what happens, because shells are
not yet all rational (some, like bash, actually did what POSIX said
should be done, which is fine when it makes sense, but not otherwise)
so applications cannot yet depend upon one behaviour or the other.

One hopes that all shells will eventually adopt rational behaviour
for this, and a later revision of the standard can reflect that.

kre

ps: this is a very similar issue/rationale as that for the function
name syntax issue discussed here not all that long ago.   functions
are commands (when invoked, not the definition) and should be treated in
as similar way as possible to any other command (builtin or in the
filesystem) as possible.   The differences we have are just because of
poor implementation choices in the early days.