2017-02-27 16:18:46 -0500, Chet Ramey: > On 2/27/17 11:50 AM, Martijn Dekker wrote: > > > So basically you're saying that, for options without a single-letter > > equivalent, "-o" options are those that are either POSIX or that you > > think should be POSIX? But then that distinction is more political than > > technical, isn't it? > > Heh. Let's just say that I'm leaving the `set -o' namespace to Posix. [...]
Well, not really since bash already has extensions over the POSIX ones. Note that all of ksh, yash and zsh at least have extensions of their own there. bash seems to be the last actively maintained POSIX-certified shell, so I don't expect POSIX would come up with option names that would conflict with bash's, so from that point of view, it would be safe to merge the name spaces. It may be worth checking other shell implementations to see if there are potential conflicts. Uniformizing between all shells would help writing scripts portable across several of the modern Bourne-like shells. zsh and yash are being conciliatory there in that they ignore case, underscore (even hyphen for yash) and treat a "no" prefix as inverting the setting. yash and zsh also accept --<option> to "set" and to the interpreter (in the case of yash, a la GNU, that is accepting unambiguous abbreviations like set --posix for set --posixlycorrect). bash also accepts --<option> (but does not support GNU-like abbreviations) for a restricted set of options like verbose/posix. See also bash --restricted vs bash -O restricted_shell (the latter one being ineffective). (that's another set of "options" that may be worth merging). So bash's shopt -s nocasematch also works as set -o nocasematch in those shells (in addition to set +o CASE_MATCH for instance). and bash's set -o posix also works (though with different effect even if the intention is the same) in zsh and yash (even if posix is not a valid option name in yash). There are things like bash.extglob vs zsh.kshglob (zsh also has zsh.extendedglob for its own extended globs) -- Stephane
