On Tue, Nov 20, 2018 at 12:47 AM Martijn van Duren < openbsd+t...@list.imperialat.at> wrote:
> When running a script with -o posix I usually do so to make sure that > the script will run anywhere with a POSIX compliant shell. Currently we > support typeset when running in posix mode, where POSIX states: > If the command name matches the name of a utility listed in the > following table, the results are unspecified[0]. > >snip< > local > >snip< > typeset > >snip< > > When looking at the rationale[1] I found the following: > Local variables within a function were considered and included in > another early proposal (controlled by the special built-in local), but > were removed because they do not fit the simple model developed for > functions and because there was some opposition to adding yet another > new special built-in that was not part of historical practice. > Implementations should reserve the identifier local (as well as typeset, > as used in the KornShell) in case this local variable mechanism is > adopted in a future version of this standard. > > I know bash supports local and dash has the keyword, but ignores its > meaning (the variables are still global), but since POSIX is pretty > vague in how the keyword should be reserved I reckon it would help > people who want to write portable scripts. > > Thoughts? Are people running -o posix in production where this could > breakage? > "set -o posix" is, IMO, about dealing with the places where ksh and posix diverge. Using it as a hammer for strict compliance eliminates that middle ground of "posix behavior with extensions". I would not consider that a positive direction. Philip Guenther
