Re: One last _values / compvalues nit, and a nasty crash bug

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> Now the bug -- press TAB three times after `: a' and get a crash:
> 
> schaefer<501> function _tv { _values -S '' -s : 'a: :(foo)' b }
> schaefer<502> compdef _tv :
> schaefer<503> function _tv { _values -S '' -s : test 'a: :(foo)' b }
> schaefer<504> : afoo:afoo:BUG: attempt to free more than allocated.
> _values:149: command not found: 0R^O^H\M-^?\M-^?\M-^?\M-^?@T^O^H\M-^?\M-^?\M-^?\M-^?pR^O^H\M-^?\M-^?\M-^?\M-^?\M-@S^O^H\M-^?\M-^?\M-^?\M-^?\M-pP^O^H\M-^?\M-^?\M-^?\M-^?ws
> zsh: segmentation fault (core dumped)  zsh-4.0.1-pre-4

That was because compvalues couldn't handle an empty string as a
separator.  It still can't, but the patch makes it test that and report
an error.  More below.

> I don't expect anyone to leap to do anything about this, but now that we
> have both -S and -s (and it's too bad their meanings aren't reversed as
> the string given to -s is the one that has to be passed to compadd -S, but
> it's too late for that now) the issue arises of what happens when you pass
> the same string to both.
> 
> E.g.:
> 
> zsh% _tv() { _values -S : -s : test 'a: :(foo)' b }
> zsh% compedef _tv :
> zsh% : a<TAB>
> zsh% : a:<TAB>
> zsh% : a:b 
> 
> At this point, the thing that comes after `a:' should have been considered
> an argument, not a new value.  If the argument to `a' is required rather
> than optional, there's no reason the same separator can't be used both
> between the value and its argument, and between the argument and the next
> value.

Yes.  Enabling it to handle this correctly would require changing the
way the current word is parsed inside the compvalues builtin (and a
change in the shell code).  And if we do that we could equally well make
it support an empty argument separator as well, although that would be
slightly more complicated because it would have to step through the
string to see if it has reached a point where the prefix matches on of
the possible values.  Then we would have to make it complete both
possible values and their arguments if we have a value which is a prefix
of another value and gets an argument (with `foo:... foobar' specs we
would have to execute the action for the argument and complete `foobar'
after `foo<TAB>').  That would then require some more changes in shell
code.

Hm.  This should still be less complicated than in _arguments and
actually seems quite doable.  I don't want to promise a working solution
any time soon, though.

Bye
  Sven

Index: Src/Zle/computil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/computil.c,v
retrieving revision 1.54
diff -u -r1.54 computil.c
--- Src/Zle/computil.c	2001/05/08 12:24:22	1.54
+++ Src/Zle/computil.c	2001/05/10 08:42:31
@@ -2096,7 +2096,7 @@
 
     while (args[0][0] == '-' && (args[0][1] == 's' || args[0][1] == 'S') &&
            !args[0][2]) {
-	if (args[1][0] && args[1][1]) {
+	if (!args[1][0] || (args[1][0] && args[1][1])) {
 	    zwarnnam(nam, "invalid separator: %s", args[1], 0);
 	    return NULL;
 	}

-- 
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx