2025年1月5日(日) 5:43 Tobi Laskowski <tobil...@outlook.com>: > 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 as Oguz pointed out. > Even with the `+u` flag, it is not possible to avoid the `nounset` > option being applied to the inner bash invocation. I confirmed this behavior, which I think is unreasonable. $ (export SHELLOPTS; set -u; bash +u -c 'echo $unset') bash: line 1: unset: unbound variable I think an option explicitly specified in the command-line arguments should take precedence over the options specified in the environment. I believe the purpose of the clause "before reading any startup files." in Bash Reference Manual is to avoid overriding the options that are explicitly set up. Then, I think SHELLOPTS shouldn't override the options explicitly specified in the command-line arguments either. > It seems the solution would be to either: > 1) Document this cascading behaviour of SHELLOPTS, and decide on the > correct behaviour of +u versus SHELLOPTS=nounset. > or > 2) Re-export only the initial value of SHELLOPTS to the new > environment, prior to modifications due to `set` or bash option > flags. Does "2" mean the environment variable SHELLOPTS and shell variable SHELLOPTS start to have effectively different values? I'm opposed to this patch because it is against the convention and extremely surprising to the users. -- Koichi
