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

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

    Date:        Tue, 26 Feb 2013 08:25:03 +0000 (UTC)
    From:        David Laight <david%l8s.co.uk@localhost>
    Message-ID:  <20130226082503.8892163E522%www.NetBSD.org@localhost>

Taking this out of gnats, as this message does not really refer to
the issue in the PR at all...

  |  So, for export and readonly, the netbsd shells are conformant.

I agree with that (and with the analogy to "local" as best it can be
applied).

But while I was looking in various places for my answer to that PR,
I came across this in the NetBSD sh man page (NetBSD 6 if that matters)

     When a shell function is executed, all of the shell positional parameters
     (except $0, which remains unchanged) are set to the arguments of the
     shell function.  The variables which are explicitly placed in the
     environment of the command (by placing assignments to them before the
     function name) are made local to the function and are set to the values
     given.  Then the command given in the function definition is executed.

The part about "The variables which are explicitly placed ..." surprised me,
as in (earlier versions) of NetBSD's sh, I'd always believed that var
assignments before func calls simply didn 't work at all.

That is, with

        f() { echo "$foo"; }

        foo=bar; foo=xxx f

would produce "bar", not "xxx" - but that's not what the man page (now) says,
and also not what happens.

Why I never complained about this in the past, is that when I researched
what was supposed to happen in the SUS, I saw this ...  (2.9.5)

        When a function is executed, it shall have the syntax-error and
        variable-assignment properties described for special built-in
        utilities in the enumerated list at the beginning of Special
        Built-In Utilities.

And then (2.14)

        Variable assignments specified with special built-in utilities
        remain in effect after the built-in completes; this shall not be
        the case with a regular built-in or other utility.

That is, in the example above, according to the SUS, after the
        foo=xxx f

the result of "echo $foo" (or just 'f' with no leading assignment)
should be xxx, but with NetBSD it is bar.

As the SUS definition of the way this is supposed to work is (IMO) nonsense,
I simply gave up on var assignments with functions as being a bad joke,
and (kind of) found another way.

The point of this message (well, the two points I guess) are to ask if the
sh & SUS experts on this list agree with my interpretation of what is
supposed to happen, and what actually happens,

And, more importantly, can I rely upon NetBSD continuing its current
practice of interpreting these things in the rational way, and that this
is going to remain one of the places where we just agree that the
standard is wrong, and ignore it, or is there a possibility that the
"standards are perfect" people will notice the difference and convince
someone to change the code to match the SUS?

If I can rely on this working properly I can simplify some of my scripts
quite a lot (they look for missing commands and supply functions to
simulate enough of the missing command to be useful for what the script
needs - by "missing commands" I mean stuff that would be installed from
pkgsrc, often, but isn't always, particularly on newly installed systems).

kre

ps: does anyone remember when this was fixed in NetBSD - I definitely recall
(and my scripts have comments in them to this effect) that it once did not
work, but that might have been a long time ago now (NetBSD 2, or even 1.x
perhaps).