> Here's the other side: allowing `set -$-' to succeed keeps a Posix-mode > shell running a script from throwing a fatal error. Allowing it also > keeps the bug reports down. The same rationale can be used to add -c and > -s to the no-op flags, since those are command-line options that end up > in $-. I know this following line of thought doesn't help much, but, have you really seen that used in the wild?
So: dualbus@hp ~ % for sh in bash dash ksh93 mksh zsh; do echo "$sh"; "$sh" -c 'set -i$-'; done bash bash: line 0: set: -c: invalid option set: usage: set [-abefhkmnptuvxBCHP] [-o option-name] [--] [arg ...] dash ksh93 ksh93: set: -i: unknown option ksh93: set: -c: unknown option Usage: set [-sabefhkmnprtuvxBCGH] [-A name] [-o[option]] [arg ...] mksh mksh: set: -i: unknown option zsh zsh:set:1: can't change option: -i Or dualbus@hp ~ % for sh in bash dash ksh93 mksh zsh; do echo "$sh"; "$sh" -c 'set -$-'; done bash bash: line 0: set: -c: invalid option set: usage: set [-abefhkmnptuvxBCHP] [-o option-name] [--] [arg ...] dash ksh93 ksh93: set: -c: unknown option Usage: set [-sabefhkmnprtuvxBCGH] [-A name] [-o[option]] [arg ...] mksh mksh: set: -c: unknown option zsh Don't seem to be very useful in general. Honestly, I'm happy with whatever path you decide to follow. The only thing I don't like about being able to turn the 'i' flag with set is that it doesn't really put the shell in interactive mode, and it bit me into thinking that it did (because the flag was showing in $-). And I don't know of a way to query the shell to print the status of the 'interactive' global var (as you can do with shopt login_shell).