From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4121 invoked by alias); 28 Feb 2017 17:08:13 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 40671 Received: (qmail 5891 invoked from network); 28 Feb 2017 17:08:13 -0000 X-Qmail-Scanner-Diagnostics: from out4-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(66.111.4.28):SA:0(-0.7/5.0):. Processed in 1.21652 secs); 28 Feb 2017 17:08:13 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) 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= X-ME-Sender: X-Sasl-enc: Oqw9Zwa/kCMVGea3GKEJN6Oocpaft4gxyXNNeenuVk67 1488301685 Date: Tue, 28 Feb 2017 17:03:29 +0000 From: Daniel Shahaf To: zsh-workers@zsh.org Subject: Re: workers/40626 (commit 6c476c22) causes multiple test failures Message-ID: <20170228170329.GA9204@fujitsu.shahaf.local2> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <170228083855.ZM7434@torch.brasslantern.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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. Cheers, Daniel