Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: characters not added in _rsync completion
- X-seq: zsh-workers 20481
- From: Wayne Davison <wayned@xxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: characters not added in _rsync completion
- Date: Wed, 13 Oct 2004 09:46:26 -0700
- In-reply-to: <Pine.LNX.4.61.0410122330050.17741@xxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20041013054015.GA824@xxxxxxxxx> <Pine.LNX.4.61.0410122330050.17741@xxxxxxxxxxxxxxxxxx>
On Tue, Oct 12, 2004 at 11:41:52PM -0700, Bart Schaefer wrote:
> I'm puzzled why the version of rsync itself makes any difference,
> because _rsync specifies everything explicitly, so unless you've
> edited _rsync it won't ever complete those options.
This is not how it works on my system. The _rsync script appears to be
querying rsync to ask it what options it supports, and combining that
list with the list in _rsync. So, if, for instance, you've installed
the rsync 2.6.3 package from debian unstable, the new options from all
the 2.6.x versions get listed, just without descriptions.
> Similarly, I have only --links and nothing else that matches --link.
Earlier rsyncs (prior to 2.6.0) didn't list --link-dest in their help
text, even when the option was supported (and our _rsync script was
missing this option as well -- I've fixed that in the latest CVS
version).
> Yet this one works for me:
> > rsync --no<TAB> # should add "-"
If I change rsync to 2.5.7 on my system, that one also begins to work.
However, with either a newer rsync (which lists --no-relative and
--no-implied-dirs in the help output) or if you edit the --no-relative
option into the _rsync script, it begins to fail.
> Without plunging into the why of it, a cursory inspection seems to
> indicate that when an option has an argument (e.g., --compa completes to
> --compare-dest= with the trailing equal sign) then zsh fails to find the
> longest common prefix among that option and any other options that do NOT
> have arguments (as --compress does not). All the cases that fail appear
> to have at least one option with, and at least one without, an argument.
It's strange that the --no<TAB> case doesn't match this idea.
..wayne..
Messages sorted by:
Reverse Date,
Date,
Thread,
Author