From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98 invoked by alias); 6 Dec 2010 10:46:29 -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: 28486 Received: (qmail 1883 invoked from network); 6 Dec 2010 10:46:23 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at csr.com does not designate permitted sender hosts) Date: Mon, 6 Dec 2010 10:46:05 +0000 From: Peter Stephenson To: zsh workers Subject: Re: _main_complete:343: bad pattern: a[ Message-ID: <20101206104605.368f920b@pwslap01u.europe.root.pri> In-Reply-To: References: <237967ef0911221022q222db8bau2ab86c82004e957@mail.gmail.com> Organization: Cambridge Silicon Radio X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Dec 2010 10:46:05.0758 (UTC) FILETIME=[C8A87DE0:01CB9532] X-Scanned-By: MailControl A_10_80_00 (www.mailcontrol.com) on 10.68.0.112 On Mon, 6 Dec 2010 02:53:44 +0100 Mikael Magnusson wrote: > On 22 November 2009 19:22, Mikael Magnusson wrote: > > % zsh -f > > % autoload -U compinit; compinit > > % $a[[ > > _main_complete:343: bad pattern: a[ > > There are lots of places in the code that say "bad pattern:", after > adding identifiers to all of them, I found it's this one in glob.c > > if (!q || errflag) { /* if parsing failed */ > restore_globstate(saved); > if (unset(BADPATTERN)) { > if (!nountok) > untokenize(ostr); > insertlinknode(list, node, ostr); > return; > } > errflag = 0; > /* $a[[ */ > zerr("bad pattern: %s", ostr); > return; > } > > around line 1730. The real weird thing is that this is triggered by > _lastcomp=( "${(@kv)compstate}" ) > in _main_complete. Trying to just echo $compstate or variations > thereof fail in the same way. Now of course I'm curious why anything > is trying to match a pattern when accessing a variable. Breaking at > the print shows this backtrace, I realize I have no idea what any of > these functions are for. The pattern match is coming from the fact that this is an assignment of an array, which does globbing. The globbing should have no effect here because there shouldn't be any patterns in the assignment. One of the values of compstate was therefore letting a token through. It looks like it was $compstate[parameter]. Any command line with compstate in it would similarly look like a failed pattern match. Index: Src/Zle/compcore.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v retrieving revision 1.101 diff -p -u -r1.101 compcore.c --- Src/Zle/compcore.c 29 Jul 2010 11:08:28 -0000 1.101 +++ Src/Zle/compcore.c 6 Dec 2010 10:44:45 -0000 @@ -648,6 +648,17 @@ callcompfunc(char *s, char *fn) else compredirs = (char **) zshcalloc(sizeof(char *)); + /* + * We need to untokenize compparameter which is the + * raw internals of a parameter subscript. + * + * The double memory duplication is a bit ugly: the additional + * dupstring() is necessary because untokenize() might change + * the string length and so later zsfree() would get the wrong + * length of the string. + */ + compparameter = dupstring(compparameter); + untokenize(compparameter); compparameter = ztrdup(compparameter); compredirect = ztrdup(compredirect); zsfree(compquote); -- Peter Stephenson Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom