_main_complete:343: bad pattern: a[

_main_complete:343: bad pattern: a[

[Mikael Magnusson]

% zsh -f
% autoload -U compinit; compinit
% $a[[<tab>
_main_complete:343: bad pattern: a[

-- 
Mikael Magnusson

Re: _main_complete:343: bad pattern: a[

[Mikael Magnusson]

On 22 November 2009 19:22, Mikael Magnusson <mikachu@gmail.com> wrote:
> % zsh -f
> % autoload -U compinit; compinit
> % $a[[<tab>
> _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[[<tab> */
	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.

I notice also that $a[[]<tab> doesn't produce an error, but then
leaves the [] in place which does produce an error when you run the
command since it's obviously broken syntax.

#0  zglob (list=0x7ffff7fee860, np=0x7ffff7feef88, nountok=0) at glob.c:1736
#1  0x00000000004810c9 in globlist (list=0x7ffff7fee860, nountok=0) at
subst.c:353
#2  0x00000000004299a9 in addvars (state=0x7fffffffc4a0, pc=0x6f2284,
addflags=0)
    at exec.c:2157
#3  0x0000000000426d83 in execsimple (state=0x7fffffffc4a0) at exec.c:1053
#4  0x00000000004270ff in execlist (state=0x7fffffffc4a0,
dont_change_job=1, exiting=0)
    at exec.c:1167
#5  0x0000000000426c88 in execode (p=0x768070, dont_change_job=1, exiting=0,
    context=0x499a0f "loadautofunc") at exec.c:1020
#6  0x000000000042f2f8 in execautofn (state=0x7fffffffcc30, do_exec=0)
at exec.c:4272
#7  0x000000000042ca77 in execcmd (state=0x7fffffffcc30, input=0,
output=0, how=18, last1=2)
    at exec.c:3120
#8  0x000000000042861f in execpline2 (state=0x7fffffffcc30, pcode=3,
how=18, input=0,
    output=0, last1=0) at exec.c:1632
#9  0x0000000000427ad2 in execpline (state=0x7fffffffcc30,
slcode=3074, how=18, last1=0)
    at exec.c:1416
#10 0x0000000000427266 in execlist (state=0x7fffffffcc30,
dont_change_job=1, exiting=0)
    at exec.c:1199
#11 0x0000000000426c88 in execode (p=0x768460, dont_change_job=1, exiting=0,
    context=0x499aa6 "shfunc") at exec.c:1020
#12 0x000000000042fe2f in runshfunc (prog=0x768460, wrap=0x0,
    name=0x7ffff7feb030 "_main_complete") at exec.c:4614
#13 0x00007ffff6b69ecf in comp_wrapper (prog=0x768460, w=0x0,
    name=0x7ffff7feb030 "_main_complete") at complete.c:1455
#14 0x000000000042fd95 in runshfunc (prog=0x768460, wrap=0x7ffff6d87d80,
    name=0x7ffff7feb030 "_main_complete") at exec.c:4599
#15 0x000000000042fb0d in doshfunc (shfunc=0x76aa20, doshargs=0x0,
noreturnval=0)
    at exec.c:4508
#16 0x00007ffff6b6c8a3 in callcompfunc (s=0x7ffff7fef690 "",
fn=0x7a5400 "_main_complete")
    at compcore.c:817
#17 0x00007ffff6b6d17e in makecomplist (s=0x7ffff7fef690 "", incmd=1, lst=0)


-- 
Mikael Magnusson

Re: _main_complete:343: bad pattern: a[

[Peter Stephenson]

On Mon, 6 Dec 2010 02:53:44 +0100
Mikael Magnusson <mikachu@gmail.com> wrote:
> On 22 November 2009 19:22, Mikael Magnusson <mikachu@gmail.com> wrote:
> > % zsh -f
> > % autoload -U compinit; compinit
> > % $a[[<tab>
> > _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[[<tab> */
> 	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 <pws@csr.com>            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