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

[tlaronde%polynum.com@localhost]

On Tue, Feb 26, 2013 at 09:58:54PM +0000, David Laight wrote:
> 
> Another thing to remember is that variable assignments inside
> functions affect the calling shell script.
> 
> This (sort of) implies and is implied by the fact that shell functions
> are executed without a fork() (as are all 'special builtins'.
> So there is no alternate (child) namespace for those (environment)
> variable assignments to be done in.
> Hence they persist in the script.

The problem is that the specification allows both interpretations,
because there is no definition of "utility" (From 2.1.6:

        The shell executes a function (see Function Definition Command ),
        built-in (see Special Built-In Utilities ), executable file, or script  
one could infer too that these are a definition of "utility") and there
is neither a definition of "Variable assignments specified with special
built-in utilities": what means "with" ? It seems at least that:

export VAR=value

sets and exports. There is no obligation to interpret this as
"assignement made at the beginning of the instruction" like in a
"custom" environment. Furthermore, this means that the behavior of an
external utility and the behavior of the same made as a function will be
different. One can prevent namespace modifications within the
implementation of a function, but one can not prevent a user to call an
external utility and a function the same way, having differing
behaviors. POSIX is about portability...

The lesson (for me) is that the spec is indeed ambiguous and that there
is no de facto standard (all shells behaving differently). So there is
no urge to change NetBSD sh to match an interpretation that is not
guaranteed to be "the" specification. Furthermore, I fail to see why a
user will write:

var=value utility

expecting var=value to remain, while simply making this an instruction
(by a newline or a semi-colon) will portably do the very same thing.

It is a little more than bikeshedding (since we need to refer to the
spec) but it is a matter of taste, not a matter of coding for the
moment, IMHO.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C