> This is already documented in a couple of different places:
Thanks for providing the relevant sections. This makes sense having read things
more thoroughly, however, most people do not read documentation from top to
bottom. Someone looking for a way to enable a shell option globally will likel
> This precdence question is really the only one. Is this issue serious
> enough to change previous behavior in an incompatible way?
To me it seems most intuitive for flags to be applied after the environment
variable, but I do not mind too much about this.
> No. That is not consistent with the
> | It is not possible to have a naive SHELLOPTS=myopt configured outside
> | the shell without all future options being exported implicitly.
> I have never used SHELLOPTS, and have never tested this, but:
> Does "unset SHELLOPTS" not work?
It gives:
bash: unset: SHELLOPTS: cannot unset
>> On the other hand, if there is a pre-existing SHELLOPTS environment variable
>> (set outside the current shell), then the `nounset` option applies to all
>> invocations of bash within the current shell.
> This is documented in the manual:
>> A colon-separated list of enabled shell options.
>
Hello,
I'd like to ask about an odd behaviour relating to the SHELLOPTS environment
variable. This is present in version 5.2.37(1)-release and in the development
version.
In this case, the `nounset` option is only applied to the current shell and not
to nested bash invocations:
> set -o nounse
