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

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

The following reply was made to PR bin/47597; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/47597: local and $() don't play well with each other
Date: Tue, 26 Feb 2013 14:03:58 +0700

     Date:        Tue, 26 Feb 2013 02:45:01 +0000 (UTC)
     From:        julio+host-netbsd-jmmv%meroh.net@localhost
     Message-ID:  <20130226024501.278CE63F087%www.NetBSD.org@localhost>
 
   |    I don't know what the expected correct behavior here is, so I cannot
   |    tell if this is a bug or not.
 
 I do not believe there is any expected behaviour, the script is beyond the
 bounds of what is intended.
 
 The man page for sh says that the syntax for local is
 
        local [variable | -] ...
 
 Nothing about assigning values as well.  That it works even partly is
 something of a fluke I'd think.
 
 The special rule about quotes not being required around variable assignments
 applies only when they are leading assignments on a (possibly null) command,
 not whenever an '=' appears in a command line anywhere.
 
 When you do (what is effectively)
 
        local a=b -c
 
 you'd be amazed if that assigned "b -c" to a, but that's just what your
 script does, as word splitting happens after command substitution.
 
 Since local isn't a standardised operator as best I can tell (pity about that)
 shells are free to implement it differently, and apparently, do.
 
 The correct way to do what you're trying (as best as "local" can ever be
 correct - which is not to bad, as just about all shells support it) is
 
 f() {
        local var
        var=$(echo a=b --c=d)   # and now the special quoting rule applies
 }
 
 Also, for what it is worth, the other issue you reported:
 
   | What strikes me as really odd is the fact that sh is raising the
   | error when the function f returns, not when var is assigned to.
 
 doesn't occur for me on NetBSD 6/i386 - the error is raised on the assignment
 (are you sure you just didn't see some artifact of mixing stderr & stdout
 in a peculiar way)?
 
 kre
 
 ps I don't want to try and fathom ksh's convoluted mechanism for local, and
 how its syntax should work in this case...    bash explicitly allows variable
 assignments in a local command.