Re: [PATCH] don't exit shell on [[ -o invalid@option ]]

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Sorry for the late response; family reasons.

Peter Stephenson wrote on Sun, Nov 12, 2017 at 19:56:57 +0000:
> On Sat, 11 Nov 2017 15:19:05 -0800
> Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > I was thinking more along the lines of tying it to EMULATION(EMULATE_SH)
> > rather directly to a given option bit.  So you get it if the shell is
> > started as sh/ksh/etc., but you can't switch it on if started as zsh.
> 
> This is tending to hide the knob under the sticky out bit at the top where
> the logo is attached (as it were).
> 
> Maybe we should just accept the original patch and note the
> incimpatibility.  It's a non-issue for properly written shell code
> anyway.

I wasn't sold by the OP's reasoning:

Martijn Dekker wrote on Fri, Nov 10, 2017 at 18:24:29 +0000:
> Does it make sense for [[ -o invalid@option ]] to exit the shell with an
> error message?
> 

Yes: "invalid@option" is neither set nor unset; it does not exist.

> Other shells with '[[' (bash, ksh93 and pdksh/mksh variants) quietly
> return an unsuccessful status for a non-existent shell option. That
> behaviour makes more sense to me because of:
> 
> (1) backwards compatibility: a script that uses '[[' to test if a shell
> option introduced in a recent zsh is set, would still work on an older
> zsh that doesn't have that shell option.
> 

That use-case is addressable by probing ${options[schroedingerscat]} or
`set -o | grep`.

As Bart hinted, the proposed change is backwards *incompatible*: it
makes [[ -o invalid@option ]] return 1 where currently it returns 2.
(User code might be relying on the distinction between $? == 1 and
$? == 2.)

Moreover, if cross-version compatibility is the goal, why is it a good
thing to lump "This shell does not have INVALID_OPTION" and "This shell
has INVALID_OPTION and it's unset"?  It's easy to imagine a situation in
which that'd be a bug: if INVALID_OPTION was added in zsh version N, is
set by default, and a plugin that was developed against version N is
installed by a user running version N-1.  With the current code that
situation would result in a (proper) warning.

I suppose we could plug the latter concern somewhat if we decided that
whenever we add a new option, it'd be unset by default.

> (2) cross-shell compatibility: treating a non-existent option as not set
> would make it easier to write a script that works on bash, ksh93, and
> pdksh/mksh as well as zsh.

Devil's advocate, but why can't people just do, today,

    if [[ -o INVALID_OPTION ]] 2>/dev/null; then

or

    if [[ ${options[invalidoption]:-off} == off ]]; then

?

Cheers,

Daniel