Re: bin/47597: local and $() don't play well with each other

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 26 Feb 2013 15:55:07 +0100
    From:        tlaronde%polynum.com@localhost
    Message-ID:  <20130226145507.GA8184%polynum.com@localhost>

OK, just one more (and last) time ...

  | I think that to link to this (2.14) section has the obvious advantage to
  | have one and only one section where rules are defined,

If that were true, it might make sense (though section 2.14 would be a
weird place to put it ... though perhaps not weirder than some other stuff
that they have).

But it isn't, the general rules for variable assignments are in 2.9.1 ...

        A "simple command" is a sequence of optional variable assignments
        and redirections, in any sequence, optionally followed by words
        and redirections, terminated by a control operator.

        [ ... general processing rules elided ... ]

        If no command name results, variable assignments shall affect the
        current execution environment. Otherwise, the variable assignments
        shall be exported for the execution environment of the command and
        shall not affect the current execution environment (except for
        special built-ins).

Now, if they'd just left it like that (with or without the text in 2.14
that just explains the processing for special built-ins more clearly) then
all would be well.

But they didn't, they added the text in 2.9.5 that makes function execution
behave like a special built-in for the purposes of variable assignments
(and syntax errors, but that's not relevant here.)   The only possible
reason for doing that is to make var assignments on function executions
persist into the current environment, just like they do with special built-ins,
as insane as that is.   That ksh implements it this way is further evidence
that this is what was intended (and most likely the cause of this intent.)

kre