Zsh Mailing List Archive
Messages sorted by:
Re: workers/40626 (commit 6c476c22) causes multiple test failures
- X-seq: zsh-workers 40671
- From: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: workers/40626 (commit 6c476c22) causes multiple test failures
- Date: Tue, 28 Feb 2017 17:03:29 +0000
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= daniel.shahaf.name; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=/HqsELDVZNjbN3k kWKR6gdXOhgg=; b=GVrXfpsX8PgpiaxmqHLXrig5adiKG2VyCleEIk+IyfqygJm JVquD5ka3YfnK3bkzCWNGXr6YdcXF8AD1r3w6Y4eFjJJ8gomlc5w0AMz0iY4G/iW 7vV3yQcOBARUcWeFXxdjZUBjY0NBNFXDUb5ieRABtI1rATJw957I7n5KQcEk=
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=/HqsELDVZNjbN3 kkWKR6gdXOhgg=; b=n6+uoLctZl3PiJD+QqwEuaUUWUhybqsArj4virzEpg9ej7 x4D8X02faI/PsVCvOkETWRJ1Id5FDGfaYttFexclAFLcWC7gkdeIFT8zluqi2Ut+ dTVyXmOczlLBeCnoSdyur/CAcJby1GZqwYD4KUaj5kXvFKx7SGoA7PZ3I1014=
- In-reply-to: <170228083855.ZM7434@torch.brasslantern.com>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <170225160455.ZM15040@torch.brasslantern.com> <20170226061620.GA3729@fujitsu.shahaf.local2> <170226114216.ZM4201@torch.brasslantern.com> <20170228074549.GA8753@fujitsu.shahaf.local2> <170228083855.ZM7434@torch.brasslantern.com>
Bart Schaefer wrote on Tue, Feb 28, 2017 at 08:38:55 -0800:
> On Feb 28, 7:45am, Daniel Shahaf wrote:
> } Subject: Re: workers/40626 (commit 6c476c22) causes multiple test failures
> } Bart Schaefer wrote on Sun, Feb 26, 2017 at 11:42:16 -0800:
> } > I suspect this is what comes of some attempt to optimize assignments.
> It occurs to me that $options et al. predate the += syntax, so this may
> just have been overlooked when adding array-append.
> } For future reference, James (who reported the original bug offlist) has
> } since reported another symptom:
> } % autoload -Uz compinit; compinit; setopt listambiguous; options+=()
> So here's my question ... why would you ever attempt to append to the
> options parameter, empty append or otherwise?
To set multiple options at once:
local -a options_to_set=( printexitvalue on warncreateglobal off )
options+=( $options_to_set )
I'm sure you can imagine how $options_to_set might be empty in one
codepath but not in another.
(The actual reason I used an empty append in the reproduction recipe
was for the sake of minimality, but that's somewhat tangential.)
> The options hash always
> contains all possible valid keys; you can't add/delete a key; you can't
> duplicate a key; so it absolutely never makes sense to append options.
> I was half of a mind to flat out make it an error, as these are ...
> torch% options[bogus]=on
> zsh: no such option: bogus
> torch% options[shwordsplit]=
> zsh: invalid value:
The append syntax doesn't accept these either:
% options+=( bogus on )
zsh: no such option: bogus
% options+=( shwordsplit '' )
zsh: invalid value:
I don't think a change is needed.
> ... until I realized that all the other zsh/parameter hashes had the
> same problem and some of them *could* sensibly be appended.
Messages sorted by: