Re: ssh completion problem

Re: ssh completion problem

[Oliver Kiddle]

[ moved to -workers ]

Bart wrote:

> when I complete after `lll@' I get offered all possible hosts from
the
> `hosts' style.  I want to be offered only `bbb.com' in that case.
> 
> (When I complete after just `l', it completes to `lll', then waits
for
> another tab.)
> 
> The problem is somehow related to this additional style:
> 
>       tag-order my-accounts \
>        'hosts:-host hosts:-domain:domain hosts:-ipaddr:IP\ address *'

I think the problem is due to this line in _combination:

compadd "$@" -a tmp || { (( $+functions[_$key] )) && "_$key" "$@" }

The line gets run for each of host hosts, domains and IP addresses.
Only one needs to fail for "_$key" (_hosts in effect) to go on to run.
This is quite possible as "$@" expands to, amoung other things, `-F
_comp_ignore'. I think the patch below is the right fix - provided tmp
can't be different with each of the tags.

We do compadd <something> || compadd <something else> in other parts of
the completion system so they may also be afflicted. As I think I've
mentioned previously, a way of specifying a default tag-order would be
better.

Oliver

--- Completion/Base/Utility/_combination      Mon Apr  2 12:10:08 2001
+++ Completion/Base/Utility/_combination      Wed Feb  6 03:21:32 2002
@@ -88,7 +88,11 @@
   fi
   tmp=( ${tmp%%${~sep}*} )
 
-  compadd "$@" -a tmp || { (( $+functions[_$key] )) && "_$key" "$@" }
+  if (( $#tmp )); then
+    compadd "$@" -a tmp 
+  elif (( $+functions[_$key] )); then
+    "_$key" "$@"
+  fi
 else
   (( $+functions[_$key] )) && "_$key" "$@"
 fi


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: ssh completion problem

[Bart Schaefer]

On Wed, 6 Feb 2002, [iso-8859-1] Oliver Kiddle wrote:

> I think the problem is due to this line in _combination:
>
> compadd "$@" -a tmp || { (( $+functions[_$key] )) && "_$key" "$@" }

Yes, I thought that was it, too.

> The line gets run for each of host hosts, domains and IP addresses.
> Only one needs to fail for "_$key" (_hosts in effect) to go on to run.

Right again, so far ... however, in looking at my own _complete_debug
output *before* applying your patch, the odd thing is that the first
compadd is failing for no apparent reason.  That is, for completion after
`lll@', it does `tmp=(bbb.com)' and `compadd -F _comp_ignore -a tmp',
but even though bbb.com is not ignored, still the compadd returns 1.

If I remove the tag-order style, that stops happening.  I don't know why
there would be any interaction between the two, but there it is.

> I think the patch below is the right fix - provided tmp can't be
> different with each of the tags.

This doesn't work as I want.  With the patch, the values from users-hosts
become the only possible matches, so I can't complete other hostnames.

Re: ssh completion problem

[Oliver Kiddle]

Bart wrote:
> 
> Right again, so far ... however, in looking at my own _complete_debug
> output *before* applying your patch, the odd thing is that the first
> compadd is failing for no apparent reason.  That is, for completion
after
> `lll@', it does `tmp=(bbb.com)' and `compadd -F _comp_ignore -a tmp',
> but even though bbb.com is not ignored, still the compadd returns 1.

I can't reproduce that.

> > I think the patch below is the right fix - provided tmp can't be
> 
> This doesn't work as I want.  With the patch, the values from
users-hosts
> become the only possible matches, so I can't complete other
hostnames.

Ah sorry, testing $#tmp was basically wrong. The correct nasty hack
would be to use compadd -O thusly:

-  compadd "$@" -a tmp || { (( $+functions[_$key] )) && "_$key" "$@" }
+  (( i=argv[(i)-F] ))
+  compadd -O all "${(@)argv[1,i]}" "${(@)argv[i+2,-1]}" -a tmp
+  if (( $#all )); then
+    compadd "$@" -a tmp 
+  elif (( $+functions[_$key] )); then
+    "_$key" "$@"
+  fi

This is working around what I think is a fundamental problem with
nested tag loops where an outer loop splits tags into labels:
Suppose that an outer tag loop separately completes several labels for
a tag and that there is an inner tag loop for which there is a defined
tag-order. It can't then be known in the inner loop if matches are
added for a tag because it might be ignoring matches for a different
label which are added after it back-tracks to the outer tags loop and
then down to the inner loop with a new tag label. Without this
knowledge, the inner loop can't know whether to allow tags which appear
later in the tag-order to be completed.

Using a tags loop in _combination runs in to problems with this. The
following patch appears to work:

-local sep tag style keys pats key num tmp
+local sep tag style keys pats key num tmp expl i all ret=1

+  _my_accounts() {
+    _wanted hosts expl host compadd "$@" -a tmp
+  }

-  compadd "$@" -a tmp || { (( $+functions[_$key] )) && "_$key" "$@" }
+  _tags "$tag" "not-$tag"
+  while _tags; do
+    (( $+functions[_$key] )) &&
+        _requested "not-$tag" expl 'ignore' "_$key" "$@" && ret=0
+    _requested "$tag" expl '' _my_accounts "$@" && ret=0
+    (( ret )) || break
+  done

More by luck than judgement however as looking up the tag-order with
the my-accounts tag is clearing _comp_ignore. The little _my_accounts
function is then needed so that we get one last _next_label loop to
separate the hosts out again.

Only dividing tags into labels before compadds might be a way to
solve this. I need to investigate further because I don't fully
understand how tags and labels work. I may have badly misunderstood
things so far. Sven?

This is unrelated but out of interest, why is the _next_labels stage
skipped in some completion functions?

Oliver

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: ssh completion problem

[Bart Schaefer]

On Fri, 8 Feb 2002, [iso-8859-1] Oliver Kiddle wrote:

> Suppose that an outer tag loop separately completes several labels for
> a tag and that there is an inner tag loop for which there is a defined
> tag-order. It can't then be known in the inner loop if matches are
> added for a tag because it might be ignoring matches for a different
> label which are added after it back-tracks to the outer tags loop and
> then down to the inner loop with a new tag label. Without this
> knowledge, the inner loop can't know whether to allow tags which appear
> later in the tag-order to be completed.
>
> Using a tags loop in _combination runs in to problems with this. The
> following patch appears to work:
>
> -local sep tag style keys pats key num tmp
> +local sep tag style keys pats key num tmp expl i all ret=1
>
> +  _my_accounts() {
> +    _wanted hosts expl host compadd "$@" -a tmp
> +  }
>
> -  compadd "$@" -a tmp || { (( $+functions[_$key] )) && "_$key" "$@" }
> +  _tags "$tag" "not-$tag"
> +  while _tags; do
> +    (( $+functions[_$key] )) &&
> +        _requested "not-$tag" expl 'ignore' "_$key" "$@" && ret=0
> +    _requested "$tag" expl '' _my_accounts "$@" && ret=0
> +    (( ret )) || break
> +  done
>
> More by luck than judgement however as looking up the tag-order with
> the my-accounts tag is clearing _comp_ignore. The little _my_accounts
> function is then needed so that we get one last _next_label loop to
> separate the hosts out again.

I tried this patch, and it doesn't seem to help.  That is, if I have a
tag-order style, I get the same behavior as the old _combination: it
completes the user part of the users-hosts from my-accounts, but then
offers all possible hosts as completions for what comes after the @.

Is there something else I should be doing, or was that patch not meant
to solve my problem?

Re: ssh completion problem

[Sven Wischnowsky]

Oliver Kiddle wrote:

> Bart wrote:
> > 
> > Right again, so far ... however, in looking at my own _complete_debug
> > output *before* applying your patch, the odd thing is that the first
> > compadd is failing for no apparent reason.  That is, for completion
> after
> > `lll@', it does `tmp=(bbb.com)' and `compadd -F _comp_ignore -a tmp',
> > but even though bbb.com is not ignored, still the compadd returns 1.
> 
> I can't reproduce that.

You need to set some ignored-patterns styles to split into host,
host-with-domain and ip-address.

> ...
> 
> Only dividing tags into labels before compadds might be a way to
> solve this. I need to investigate further because I don't fully
> understand how tags and labels work. I may have badly misunderstood
> things so far. Sven?

Your analysis is basically right, the problem is that _combination
doesn't know whether there might be other matches be added for the tag
by an outer loop. So I think what is wrong here is _combination adding
default matches. I'd think that's simlpy the wrong place to do that.

One way to circumvent most problems with tag and label loops is to
make _combination loop:

--- Completion/Base/Utility/_combination	Mon Apr  2 13:10:08 2001
+++ _combination	Mon Feb 11 09:38:06 2002
@@ -88,7 +88,9 @@
   fi
   tmp=( ${tmp%%${~sep}*} )
 
-  compadd "$@" -a tmp || { (( $+functions[_$key] )) && "_$key" "$@" }
+  local expl
+  _wanted $key expl $key  compadd "$@" -a tmp ||
+      { (( $+functions[_$key] )) && "_$key" "$@" }
 else
   (( $+functions[_$key] )) && "_$key" "$@"
 fi


This patch can't be complete, though (only something to play with and
then decide if we want to go this way), because to make this right we
need to pass _combination a description.

> This is unrelated but out of interest, why is the _next_labels stage
> skipped in some completion functions?

Could you ive me an example, so that I don't need to search?


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: ssh completion problem

[Bart Schaefer]

On Mon, 11 Feb 2002, Sven Wischnowsky wrote:

> One way to circumvent most problems with tag and label loops is to
> make _combination loop:
>
[...]
>
> This patch can't be complete, though (only something to play with and
> then decide if we want to go this way), because to make this right we
> need to pass _combination a description.

Just for the record, I applied this patch and it appears to do exactly
what I wanted.  The only missing bit -- which I don't mind, but it came
up on another thread recently -- is that it takes two TABs (one for the
user part, and one for the host part) to complete one of the users-hosts
values, even if there's only one that matches the user part.

Thanks, Sven.

Re: ssh completion problem

[Oliver Kiddle]

 --- Bart Schaefer <schaefer@brasslantern.com> wrote:

> I tried this patch, and it doesn't seem to help.  That is, if I have
a
> tag-order style, I get the same behavior as the old _combination: it
> completes the user part of the users-hosts from my-accounts, but then
> offers all possible hosts as completions for what comes after the @.
> 
> Is there something else I should be doing, or was that patch not
> meant to solve my problem?

Did you try the first patch? The second patch was there because it
demonstrates why I think this problem is more fundamental than just
_combination. If you just want to get this working, Sven's patch is
now perhaps a better bet as I see you've now done. Needing two tabs
is a separate issue which has come up before. A possible solution
to that might be some value in compstate which if set causes
completion to have another go if a first match was unambiguously
added. It'll be more complicated if l@b is to complete to lll@bbb.com
though.

Sven Wischnowsky <wischnow@berkom.de> wrote:

> > I can't reproduce that.
> 
> You need to set some ignored-patterns styles to split into host,
> host-with-domain and ip-address.

I did have ignored-patterns styles set - '*.*' (host), '^[^0-9]*.*'
(domain) and '^[0-9.]#' (ipaddr). Perhaps Bart's use of different
patterns was significant though.

> Your analysis is basically right, the problem is that _combination
> doesn't know whether there might be other matches be added for the
> tag
> by an outer loop. So I think what is wrong here is _combination
> adding
> default matches. I'd think that's simlpy the wrong place to do that.

Where is the right place to add default matches then? Having a way to
specify a default tag-order would seem the most logical to me.

> One way to circumvent most problems with tag and label loops is to
> make _combination loop:

With this there is then two loops for the hosts tag. The inner loop
allows it to loop over the three labels again so it knows if matches
are added for each label or not. Note that there are then nine calls to
compadd. It only works because the final (innermost) label loop is for
the same tag that is separated into labels. I still am convinced that
there is a wider problem which this doesn't solve. The second patch
in my last post is a useful one for seeing the problems.

> > This is unrelated but out of interest, why is the _next_labels
stage
> > skipped in some completion functions?
> 
> Could you give me an example, so that I don't need to search?

_netscape. There's also a few cases which look like `_requested users
&& _users && ret=0' but I suppose they're okay because of _users
calling _wanted? 

Oliver

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: ssh completion problem

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> Did you try the first patch? The second patch was there because it
> demonstrates why I think this problem is more fundamental than just
> _combination. If you just want to get this working, Sven's patch is
> now perhaps a better bet as I see you've now done. Needing two tabs
> is a separate issue which has come up before.

Right, I forgot to answer that.

> A possible solution
> to that might be some value in compstate which if set causes
> completion to have another go if a first match was unambiguously
> added.

I'd try to do that all in shell code, i.e. in _main_complete, but, as
with the fake style, ...

> It'll be more complicated if l@b is to complete to lll@bbb.com
> though.

...I think we should also do that in those utility functions, where it
is useful, i.e. _user_at_host. At least that was the idea we had at
the bginning, leading to functions like _sep_parts.

> ...
> 
> > Your analysis is basically right, the problem is that _combination
> > doesn't know whether there might be other matches be added for the
> > tag
> > by an outer loop. So I think what is wrong here is _combination
> > adding
> > default matches. I'd think that's simlpy the wrong place to do that.
> 
> Where is the right place to add default matches then?

In the function where the outer loops are, because only there can we
know what other things are to be completed (after all, it's not only
different labels, there might be completely other types of matches --
different tags -- the outermost function will offer).

Of course, as can be seen by the _combination example we are talking
about, functions in the inner circle might have good ideas about *how*
to produce those matches. I've been realtively silent not only because
I have a lot of work here, but also because I'm trying to find a
generic approach to all this.

> Having a way to
> specify a default tag-order would seem the most logical to me.

I'd like to hear more about this (so that I understand what exactly
you mean) and how it could solve -- as an example -- the case we are
discussing here. Maybe you are thinking about something similar and
have a solution in mind?

> > One way to circumvent most problems with tag and label loops is to
> > make _combination loop:
> 
> With this there is then two loops for the hosts tag. The inner loop
> allows it to loop over the three labels again so it knows if matches
> are added for each label or not. Note that there are then nine calls to
> compadd. It only works because the final (innermost) label loop is for
> the same tag that is separated into labels. I still am convinced that
> there is a wider problem which this doesn't solve. The second patch
> in my last post is a useful one for seeing the problems.

Yes, I know how this works ;-) And I also see that this is a wider
problem (see above). If I had thought this were the solution, I'd have
committed the patch.

> > > This is unrelated but out of interest, why is the _next_labels
> stage
> > > skipped in some completion functions?
> > 
> > Could you give me an example, so that I don't need to search?
> 
> _netscape. There's also a few cases which look like `_requested users
> && _users && ret=0' but I suppose they're okay because of _users
> calling _wanted? 

I don't see such a case there. Are you aware that _wanted and
_requested use _all_labels which implements the labels-loop?


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: ssh completion problem

[Oliver Kiddle]

Sven Wischnowsky wrote:

> >  Needing two tabs is a separate issue which has come up before.

> > It'll be more complicated if l@b is to complete to lll@bbb.com
> > though.
> 
> ...I think we should also do that in those utility functions, where
> it
> is useful, i.e. _user_at_host. At least that was the idea we had at
> the bginning, leading to functions like _sep_parts.

It's easier for _sep_parts though because all it has is an array of
values for each part. I have at home a _sep_parts like function which
takes _alternative like specs so can call things like _user. Without
relying on compadd's -O, I couldn't see how to get it to do this sort
of thing.

> > Where is the right place to add default matches then?
> 
> In the function where the outer loops are, because only there can we

Seems a pity not to allow utility functions to define the default
orders for the things it completes. It reduces the flexibility of
functions in
the inner circle.

> > Having a way to
> > specify a default tag-order would seem the most logical to me.
> 
> I'd like to hear more about this (so that I understand what exactly
> you mean) and how it could solve -- as an example -- the case we are
> discussing here. Maybe you are thinking about something similar and
> have a solution in mind?

Firstly, I should point out that I don't think this is a solution to
the problem. It is just that setting defaults with || is inflexible.

The idea is simple though. _tags looks up tag-order right? So if _tags
takes an option which specifies a default tag-order. This default is
used unless overriden by a tag-order style.

So instead of:
   compadd -a tmp || _hosts
we can do
_tags -o '"my-accounts" "not-my-accounts"' my-accounts not-my-accounts
and then the usual tags loop. A user can then change the default order
with a style. We'd need some care to ensure that matches are all added
to the hosts group with a `host' description (I don't see why they
should be necessary to _requested and friends for the many cases when
you just want to pass down the values set in an outer loop (which you
have in "$@")).

One idea I have for solving the main part of the problem is only doing
a _next_labels loop around final compadd commands. This loop would need
to loop over all labels for every tag for which an _requested is in our
funcstack. It would lose some flexibility such as a tag-order like:
  'hosts:-domain users' 'hosts:-ipaddr ports'
no longer being possible (so there might aswell then be a separate
label-order style) but such tag-orders only currently work if there is
no tag loop nesting. Also, when looking up the ignored-patterns style,
the _comp_ignore array needs to be augmented so it needs to be
implemented as a sort of stack. I think this solution would lack the
fundamental problems though it does have limitations so I'll be doing
some further thinking. 

> Yes, I know how this works ;-) And I also see that this is a wider
> problem (see above). If I had thought this were the solution, I'd
> have committed the patch.

Sorry, I was under the impression that you thought that patch was a
solution once we'd got the description down to _combination.

> > _netscape. There's also a few cases which look like `_requested

> I don't see such a case there. Are you aware that _wanted and
> _requested use _all_labels which implements the labels-loop?

I'd have expected an _requested if around the _next_label prefixes loop
and an _next_labels loop inside the _requested urls if. I thought
_requested only used _all_labels if it got description arguments.

Cheers

Oliver
PS. You may know anyway but with the recent fake style patch (I think
the _wanted -x one) which you haven't commited, I get problems with
descriptions. grep -<tab> for example lists options and descriptions
separately. I haven't tried the very latest patch which has just
arrived in the last few minutes.

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: ssh completion problem

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> > > Where is the right place to add default matches then?
> > 
> > In the function where the outer loops are, because only there can we
> 
> Seems a pity not to allow utility functions to define the default
> orders for the things it completes. It reduces the flexibility of
> functions in
> the inner circle.

Yes, that's why I'd like to find a nice solution...

> ...
> 
> The idea is simple though. _tags looks up tag-order right? So if _tags
> takes an option which specifies a default tag-order. This default is
> used unless overriden by a tag-order style.

Ahh. I was mostly wondering where you wanted to put those defaults.
On that lavel, aha, interesting.

> So instead of:
>    compadd -a tmp || _hosts
> we can do
> _tags -o '"my-accounts" "not-my-accounts"' my-accounts not-my-accounts
> and then the usual tags loop. A user can then change the default order
> with a style. We'd need some care to ensure that matches are all added
> to the hosts group with a `host' description (I don't see why they
> should be necessary to _requested and friends for the many cases when
> you just want to pass down the values set in an outer loop (which you
> have in "$@")).

Hmhm, compadd-option-inheritance is something I've been thinking
about, too, lately, in the fake-style discussion.

> One idea I have for solving the main part of the problem is only doing
> a _next_labels loop around final compadd commands. This loop would need
> to loop over all labels for every tag for which an _requested is in our
> funcstack. It would lose some flexibility such as a tag-order like:
>   'hosts:-domain users' 'hosts:-ipaddr ports'
> no longer being possible (so there might aswell then be a separate
> label-order style) but such tag-orders only currently work if there is
> no tag loop nesting. Also, when looking up the ignored-patterns style,
> the _comp_ignore array needs to be augmented so it needs to be
> implemented as a sort of stack. I think this solution would lack the
> fundamental problems though it does have limitations so I'll be doing
> some further thinking. 

But interesting ideas already...

> ...
> 
> > > _netscape. There's also a few cases which look like `_requested
> 
> > I don't see such a case there. Are you aware that _wanted and
> > _requested use _all_labels which implements the labels-loop?
> 
> I'd have expected an _requested if around the _next_label prefixes loop

That's only needed when there are two or more possible tags. If the
only tag offered isn't wanted by the user the _tags in the while loop
never returns non-zero (and hence we don't really need a loop there).

> and an _next_labels loop inside the _requested urls if. I thought
> _requested only used _all_labels if it got description arguments.

That's left to the _wanted, _newsgroups and that _tags-loop, it seems.

> PS. You may know anyway but with the recent fake style patch (I think
> the _wanted -x one) which you haven't commited, I get problems with
> descriptions. grep -<tab> for example lists options and descriptions
> separately. I haven't tried the very latest patch which has just
> arrived in the last few minutes.

Yes, I know, it was caused by the changes in the C-code and hence I
didn't commit that part.


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: ssh completion problem

[Oliver Kiddle]

 --- Sven Wischnowsky <wischnow@berkom.de> wrote: > 

> > One idea I have for solving the main part of the problem is only
> doing
> > a _next_labels loop around final compadd commands. This loop would
> need
> > to loop over all labels for every tag for which an _requested is in
> our
> > funcstack. It would lose some flexibility such as a tag-order like:
> >   'hosts:-domain users' 'hosts:-ipaddr ports'
> > no longer being possible ...

> >  ... limitations so I'll be doing some further thinking. 

> But interesting ideas already...

The only other solution I've thought of would be to defer all tag/label
loops until the very end after all matches are added. It'd need to
track the path of added matches building up a list of associated tags.
It would allow the mixed label/tag tag-orders like the example above
but be less efficient because unwanted matches would be generated.

I think I prefer my first idea which also has the advantage of being
closer to the current system. I don't think separate tag and label
ordering would matter much. I've still got some lines of thought I want
to follow though.

If the tags dependence on funcstack to track nested tags loops goes, we
may need to act on a tag loop exiting. Currently, we break out of the
loops with `(( ret )) || break'. Can't that be done with a
compstate[nmatches] test in _tags - I'd prefer if we didn't have to set
and test $ret there anyway.

> > I'd have expected an _requested if around the _next_label prefixes
> loop
> 
> That's only needed when there are two or more possible tags. If the
> only tag offered isn't wanted by the user the _tags in the while loop
> never returns non-zero (and hence we don't really need a loop there).

Ah, that explains.

> > and an _next_labels loop inside the _requested urls if. I thought
> > _requested only used _all_labels if it got description arguments.
> 
> That's left to the _wanted, _newsgroups and that _tags-loop, it
> seems.

Okay, but those _wanted calls use a different tag. Labels setup for the
urls tag might not then be handled.

Cheers

Oliver

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: ssh completion problem

[Sven Wischnowsky]

I wrote:

> ...
> 
> > PS. You may know anyway but with the recent fake style patch (I think
> > the _wanted -x one) which you haven't commited, I get problems with
> > descriptions. grep -<tab> for example lists options and descriptions
> > separately. I haven't tried the very latest patch which has just
> > arrived in the last few minutes.
> 
> Yes, I know, it was caused by the changes in the C-code and hence I
> didn't commit that part.

Here is an improved patch for that part. I was gettng doubled
descriptions (they got added to the wrong group in some cases).

Bye
  Sven

Index: Src/Zle/compcore.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v
retrieving revision 1.53
diff -u -r1.53 compcore.c
--- Src/Zle/compcore.c	22 Jan 2002 10:22:48 -0000	1.53
+++ Src/Zle/compcore.c	18 Feb 2002 14:29:22 -0000
@@ -1619,6 +1619,21 @@
     Heap oldheap;
 
     SWITCHHEAPS(oldheap, compheap) {
+        if (dat->dummies)
+            dat->aflags = ((dat->aflags | CAF_NOSORT | CAF_UNIQCON) &
+                           ~CAF_UNIQALL);
+
+        /* Select the group in which to store the matches. */
+        gflags = (((dat->aflags & CAF_NOSORT ) ? CGF_NOSORT  : 0) |
+                  ((dat->aflags & CAF_UNIQALL) ? CGF_UNIQALL : 0) |
+                  ((dat->aflags & CAF_UNIQCON) ? CGF_UNIQCON : 0));
+        if (dat->group) {
+            endcmgroup(NULL);
+            begcmgroup(dat->group, gflags);
+        } else {
+            endcmgroup(NULL);
+            begcmgroup("default", 0);
+        }
         if (dat->mesg || dat->exp) {
             curexpl = (Cexpl) zhalloc(sizeof(struct cexpl));
             curexpl->always = !!dat->mesg;
@@ -1630,25 +1645,13 @@
             curexpl = NULL;
     } SWITCHBACKHEAPS(oldheap);
 
-    if (!*argv && !dat->dummies && !(dat->aflags & CAF_ALL)) {
-	SWITCHHEAPS(oldheap, compheap) {
-	    /* Select the group in which to store the matches. */
-	    gflags = (((dat->aflags & CAF_NOSORT ) ? CGF_NOSORT  : 0) |
-		      ((dat->aflags & CAF_UNIQALL) ? CGF_UNIQALL : 0) |
-		      ((dat->aflags & CAF_UNIQCON) ? CGF_UNIQCON : 0));
-	    if (dat->group) {
-		endcmgroup(NULL);
-		begcmgroup(dat->group, gflags);
-	    } else {
-		endcmgroup(NULL);
-		begcmgroup("default", 0);
-	    }
-	} SWITCHBACKHEAPS(oldheap);
-
+    if (!*argv && !dat->dummies && !(dat->aflags & CAF_ALL))
 	return 1;
-    }
+
+#if 0
     if (dat->dummies)
         dat->aflags = (dat->aflags | CAF_NOSORT | CAF_UNIQCON) & ~CAF_UNIQALL;
+#endif
     for (bp = brbeg; bp; bp = bp->next)
 	bp->curpos = ((dat->aflags & CAF_QUOTE) ? bp->pos : bp->qpos);
     for (bp = brend; bp; bp = bp->next)
@@ -1880,17 +1883,6 @@
 			haspattern = 1;
 		}
 	    }
-	}
-	/* Select the group in which to store the matches. */
-	gflags = (((dat->aflags & CAF_NOSORT ) ? CGF_NOSORT  : 0) |
-		  ((dat->aflags & CAF_UNIQALL) ? CGF_UNIQALL : 0) |
-		  ((dat->aflags & CAF_UNIQCON) ? CGF_UNIQCON : 0));
-	if (dat->group) {
-	    endcmgroup(NULL);
-	    begcmgroup(dat->group, gflags);
-	} else {
-	    endcmgroup(NULL);
-	    begcmgroup("default", 0);
 	}
 	if (*argv) {
 	    if (dat->pre)

-- 
Sven Wischnowsky                          wischnow@berkom.de