>> 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. >> If this variable is in the environment when Bash starts up, each shell >> option in the list will be enabled before reading any startup files. This does not cover the specific behaviour I am concerned with. I would expect something like: "Additionally, if it is in the environment at start up, the variable is automatically exported and shell options enabled subsequently through other means will be included in the exported value." I do not find it surprising that the values in SHELLOPTS are applied, I find it surprising that the pre-existence of a SHELLOPTS environment variable results in any future shell options being "sticky". It is not possible to have a naive SHELLOPTS=myopt configured outside the shell without all future options being exported implicitly. Perhaps the problem is that the given use-case abuses SHELLOPTS as if it also fulfilled the role of a DEFAULT_SHELLOPTS environment variable, i.e. one that sets some initial shell options but does not imply that SHELLOPTS itself should be exported. > Try BASH_ENV instead: > https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html#index-BASH_005fENV If this is the correct way to achieve this, that is fair enough. If SHELLOPTS is not intended to be used in this way then I would expect the documentation to include enough information that would discourage a user from falling into this trap. -- Tobi
