From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 781 invoked by alias); 21 Sep 2013 23:35:28 -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: 31739 Received: (qmail 20891 invoked from network); 21 Sep 2013 23:35:22 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <130921163531.ZM18698@torch.brasslantern.com> Date: Sat, 21 Sep 2013 16:35:31 -0700 In-reply-to: <130921013028.ZM17637@torch.brasslantern.com> Comments: In reply to Bart Schaefer "Re: question about glob qualifier format (#qx)" (Sep 21, 1:30am) References: <20130920111110.GA4501@localhost.localdomain> <20130920123830.30111071@pwslap01u.europe.root.pri> <20130920233930.GB4501@localhost.localdomain> <130921013028.ZM17637@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: zpc_special [was Re: question about glob qualifier format (#qx)] MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Sep 21, 1:30am, Bart Schaefer wrote: } } I accidentally encountered some odd behavior while confirming this. } With NO_EXTENDED_GLOB, #q is not supposed to be available to introduce } qualifiers. However } } % setopt NO_EXTENDED_GLOB } % echo *(#q@) } } } Whereas } } % echo *(#q/) } zsh: unknown file attribute } } This is inconsistent, that is, sometimes (#q@) will also give "unknown" } and (#q/) will work. I believe this has to do with the new zpc_special[] array in pattern.c. The first time we enter zglob(), it has not been initalized yet (?) and so "#" is believed to be an active pattern chracter even though the EXTENDED_GLOB option may not be set. The next time through zpc_special will have been initialized, but it doesn't get re-initialized when the extendedglob option is toggled (?) so the parsing of "#" may be left in the wrong state. Or something along those lines; PWS will have a better idea what is going on, I hope. I suspect glob.c:zglob() needs to call pattern.c:patparsecharset() before it begins parsing the qualifiers, but the latter is static in parse.c, so it isn't called until zglob() calls parsepat() much later, and I don't follow the ramifications of calling patparsecharset() more than once for the same pattern because the whole array gets clobbered and reset on each call. Maybe harmless, I again hope PWS will have a better idea.