Re: _multi_parts and -q

[Danek Duvall <duvall@xxxxxxxxxxxxxx>]

On Sat, Jun 18, 2011 at 10:07:23PM +0100, Peter Stephenson wrote:

> On Sat, 18 Jun 2011 13:03:34 -0700
> Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>  On Jun 18,  8:52pm, Peter Stephenson wrote:
> > } 
> > } _tst() {
> > }   local expl_type="stuff"
> > }   local -a datasetlist
> > }   datasetlist=(foo bar rod stuff)
> > }   local pref
> > }   [[ $PREFIX = */* ]] && pref=${PREFIX%/*} 
> > }   [[ -n $pref ]] && datasetlist=($pref/${^datasetlist})
> > }   _wanted dataset expl "$expl_type" _multi_parts -S/ -q / datasetlist;
> > } }                     
> > } 
> > } simply to get strings to compile.  I don't think that should matter.
> > 
> > I get Danek's reported behavior if the strings in datasetlist actually
> > contain the separator.  Try the above with
> > 
> > datasetlist=(xy/foo xy/bar yx/rod stuff xy/yx/xy)
> > 
> > So perhaps Danek's problem is with the input data?

For context, this in my _zfs_dataset function, which at the moment passes
neither -S nor -q to _multi_parts, but I tried doing that to try to get the
slash auto-removed.

datasetlist contains the entire list of datasets on the system, mostly
because it's cheaper to generate the entire list once instead of at each
level.  So it contains data like

    xy xy/foo xy/foo/bar xy/foo/baz xy/qux xy/qux/baz

just like a directory structure.  Then if I type "x<TAB>", I get "xy/".  If
I type "/", I still have only one slash, but if I hit space or return, then
the slash stays.  And "xy/" is not valid, and the command complains.  Which
I guess is this observation:

> I'm seeing something similar with the "xy/" bit with that data, i.e
> completing "x" produces "xy/" with a non-removable "/".

> I think the issue is that "xy/foo", "xy/bar" etc. look like a set of
> ambiguous completions with "xy/" as prefix --- and in *that* case the
> "/" isn't special, it's just part of the input string.  (Possibly you
> can see some behaviour that disagrees with this hypothesis.)
> 
> So the reason I wasn't seeing it is that I was only offering completions
> for the current level, i.e. I'd only be offering "xy", "yx" and "stuff"
> at this point, after which the "/" is a suffix & separator with the
> expected behaviour.
> 
> So if it's possible to generate the completions in that fashion (some
> more sophisticated variant of the ${PREFIX%/*} business in the function
> I was using), I think that would be a workaround.

How can I do that without regenerating datasetlist multiple times --
calling zfs list over and over again is not cheap (but not really something
I want to cache using _store_cache, etc, either, if for no other reason
than I have no way of knowing whether the cache is invalid).

Thanks,
Danek