From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: zsh-workers@zsh.org
Subject: Re: [PATCH] don't exit shell on [[ -o invalid@option ]]
Date: Tue, 14 Nov 2017 12:26:19 +0000 [thread overview]
Message-ID: <20171114122619.kqa4i2sth66mafrs@tarpaulin.shahaf.local2> (raw)
In-Reply-To: <20171112195657.74fb0b8a@ntlworld.com>
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@brasslantern.com> 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
next prev parent reply other threads:[~2017-11-14 12:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-10 18:24 Martijn Dekker
2017-11-10 18:53 ` Eric Cook
2017-11-10 19:03 ` Martijn Dekker
2017-11-10 22:37 ` Bart Schaefer
2017-11-11 12:45 ` Peter Stephenson
2017-11-11 19:01 ` Martijn Dekker
2017-11-11 23:19 ` Bart Schaefer
2017-11-12 19:56 ` Peter Stephenson
2017-11-14 12:26 ` Daniel Shahaf [this message]
2017-11-14 13:22 ` Martijn Dekker
2017-11-14 23:52 ` Daniel Shahaf
2017-11-16 0:52 ` Martijn Dekker
2017-11-18 18:22 ` Daniel Shahaf
2017-11-19 14:46 ` Martijn Dekker
2017-11-19 19:41 ` Bart Schaefer
2017-11-19 19:53 ` Peter Stephenson
2017-11-20 1:22 ` Daniel Shahaf
2017-11-24 21:50 ` Daniel Shahaf
2017-12-03 7:28 ` Mikael Magnusson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171114122619.kqa4i2sth66mafrs@tarpaulin.shahaf.local2 \
--to=d.s@daniel.shahaf.name \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).