On Wed, Oct 25, 2017 at 11:32:51PM -0700, Jeff King wrote: > On Wed, Oct 25, 2017 at 10:03:09AM +0200, Michael Haggerty wrote: > > > > Yeah. It's supported by dash and many other shells, but we do try to > > > avoid it[1]. I think in this case we could just drop it (but keep > > > setting the "local foo" ones to empty with "foo=". > > > > I do wish that we could allow "local", as it avoids a lot of headaches > > and potential breakage. According to [1], > > Agreed. This would be useful. Debian requires that all implementations that implement /bin/sh support local and a small number of other features. There is discussion in the Austin Group issue tracker about adding this feature to POSIX, but it's gotten bogged down over lexical versus dynamic scoping. Everyone agrees that it's a desirable feature, though. > > He mentions that ksh93 doesn't support "local", but that it differs from > > POSIX in many other ways, too. > > Yes, the conclusion we came to in the thread I linked earlier is the > same: ksh is affected, but that shell is a problem for other reasons. I > don't know if anybody tested with "modern" ksh like mksh, though. Should > be easy enough: As far as I can tell, bash, dash, posh, mksh, pdksh, zsh, and busybox sh all support local. From my reading of the documentation, so does sh on FreeBSD, NetBSD, and OpenBSD. Not all of these are good choices for a POSIXy sh, though. ksh93 will support local if you alias it to typeset, but only when called from functions defined with "function", not normal shell-style functions. I have a gist[0] that does absurd things to work around that, but I wouldn't recommend that for production use. Solaris 11.1's man page doesn't document local in sh (which is a ksh88 variant) and ksh is ksh93, so it doesn't appear to support it. Solaris 11.3 documents bash, so it's a non-issue there. It's my understanding that using ksh as a POSIXy sh variant is very common on proprietary Unices, so its lack of compatibility may be a dealbreaker. Then again, many of those systems may have bash installed. > > Perhaps we could slip in a couple of "local" as a compatibility test to > > see if anybody complains, like we did with a couple of C features recently. > > That sounds reasonable to me. But from the earlier conversation, beware > that: > > local x > ... > x=5 > > is not necessarily enough to notice the problem on broken shells (they > may complain that "local" is not a command, and quietly stomp on the > global). I think: > > local x=5 > > would be enough (though depend on how you use $x, the failure mode might > be pretty subtle). Or we could even add an explicit test in t0000 like > the example above. I'd recommend an explicit test for this. It's much easier to track down that way than seeing other failure scenarios. People will also usually complain about failing tests. [0] https://gist.github.com/bk2204/9dd24df0e4499a02a300578ebdca4728 -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
