On 11/21/18 2:19 AM, Philip Guenther wrote:
> 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
>
ACK, I'll drop this.
