Control: tags -1 + moreinfo While taking care of old bugs, I noticed that this one is being updated with tags for all newer Debian release (jessie, stretch, and buster). However, I'm not sure I can actually reproduce the related problems, so I'm asking for more information.
On Mon, 21 Jun 2010 14:04:12 -0400 Pierre St Juste <[email protected]> wrote: > > When I run > > rsync -av TAB > > I takes a few seconds to show options even when there are only a few > options. This is recent (within past few weeks), it was much faster in > the past. In a freshly debootstrapped chroot (with debian stretch or debian unstable), it works fast enough that I can't see a delay: # ls matrix-calculus.tex # rsync -av ::1: ip6-allnodes: ip6-loopback: ff02::1: ip6-allrouters: localhost: ff02::2: ip6-localhost: matrix-calculus.tex On the machine I use on a daily basis, there are more entries, however, the output is still too fast for me to notice. On Tue, 16 Nov 2010 12:48:48 +0000 "Barak A. Pearlmutter" <[email protected]> wrote: > I'd like to put in my two cents on this issue: I find the current > behaviour slow and also somewhat annoying, and would urge this bug be > addressed. In fact, I think it is serious enough for a fix to get > through the freeze and into squeeze. > > My logic follows. > > The remote-machine completion (a) is excruciating slow most of the > time, and (b) interferes with completion of local filenames which is > what I pushed <TAB> for about 99% of the time. > > Unless there is some way to set a 500ms timeout on the network part of > the rsync completion, I would urge a change to the package to have > rsync complete local filenames only: no local hostname completion, no > remote filename completion. Maybe there could be an easy-to-set flag > to turn on remote completion, for those who so desire. Regarding the "no local hostname completion" part, there is a flag for disabling completion with AVAHI and that is disabled by default (COMP_KNOWN_HOSTS_WITH_AVAHI) [1]. As a matter of fact, in Debian, it is hardcoded as disabled by a local patch [2] (the main upstream developer, Ville Skyttä, already told me in a private email that the patch is not be needed). [1] https://github.com/scop/bash-completion/blob/master/doc/bash_completion.txt#L57-L60 [2] https://salsa.debian.org/debian/bash-completion/blob/master/debian/patches/03-disable_avahi_browse.patch Maybe this would solve your concern about completion taking too long to display an output (more on this topic at the very end of this message). > (Remote > filename completion after the colon has been typed would be sort-of > okay, but even that is a bit slow and really should have a stringent > timeout mechanism. And is also not always what I want: typically I > construct a remote target filename out of bits and pieces of local > filenames, and would in fact find local completion more useful even > when typing a string that will be used as a remote filename.) I got the impression that you are OK with the current behavior, so I'll refrain from making further comments. If you think that should be addressed, please let me know (actually, please consider opening a new bug report for this specific matter). > It is also interesting to note that the current remote completion > policy is a potential security problem, as it can cause ssh to make > credential-passing connections to remote hosts without the user > knowing about it. This leaks information about what the user has > typed, complete with typos, via both DNS and, when hostnames resolve, > unsuccessful SSH connection attempts. It also allows denial of > service attacks, by disrupting the above mechanisms. Similarly, this seems unrelated to the bug at hand. Maybe we should move it to a new bug report so that it can be forwarded to people with more experience in security issues (I have very little). > The current completion also often gets things plain wrong, as in: > > $ rsync --rsh=s<TAB> > scriptng.local: sonja-laptop.local: source5ng.local: In a freshly debootstrapped chroot (with debian stretch or debian unstable), I don't get these options. Here's what I actually get: # rsync --rsh=[TAB][TAB] rsh ssh > Here my shell freezes for an excruciatingly long time > > $ rsync --rsh= <TAB> > [[[ SEVEN SECOND DELAY GOES HERE ]]] > $ rsync --rsh= <TAB><TAB> > [[[ FIFTEEN SECOND DELAY GOES HERE ]]] > ::1: hmm.ps > online-freq.tex > arrakis.local: hmm.tex pandora.local: > buket-laptop.local: ip6-allnodes: piggy.local: > [etc.] Likewise, with current bash-completion I get different results (and the results are outputted instantly): # rsync --rsh= [TAB][TAB] ::1: ip6-allnodes: ip6-loopback: ff02::1: ip6-allrouters: localhost: ff02::2: ip6-localhost: matrix-calculus.tex On the machine I use on a daily basis, there are more entries, however, the output is still too fast for me to notice. > This is another example of what I do not think anyone wants: > > $ ls m* > matrix-calculus.tex > > $ rsync --verbose m<TAB> > $ rsync --verbose ma<TAB> > mars.local: matrix-calculus.tex > > Do people care about a visitor's laptop connected to the local network > that happens to be named "mars"? Should its presence corrupt and > delay local filename completion? I'd say: no. I don't think the behaviour is wrong and people might want it. Maybe an option to disable hostname completion (as you mentioned above) could be added to upstream bash-completion (I'll try to write it myself, but I can't promise anything, because I'm not that experienced with the upstream source-code).
