SSH hostname completion with common suffix and globcomplete inserts characters

SSH hostname completion with common suffix and globcomplete inserts characters

[Daniel Hahler]

[-- Attachment #1.1: Type: text/plain, Size: 1082 bytes --]

When using TAB completion (via expand-or-complete, and "setopt
globcomplete") on a partial hostname where alternatives with a common
suffix exist, the second invocation of TAB will insert some character(s)
that make it fail to complete afterwards.


% autoload -Uz compinit
% compinit
% echo "Host test-05827d88.foo.bar test-6cae9ce0.foo.bar" > ssh_config
% setopt globcomplete

With

% ssh -F ssh_config test-<TAB>

You will get:

% ssh -F ssh_config test-|.foo.bar

Pressing TAB again results in:

% ssh -F ssh_config test-|BR.foo.bar

The characters being inserted seem to come from the "bar".

With ".dot.com" at the end I am seeing "CM" being inserted.

With "Host test-05.dot.com test-6c.dot.com" however "D" is being
inserted.

And with a single TLD (i.e. "test-05827d88.com test-6cae9ce0.com") it
works.

In _ssh_hosts the following is used, which seems to be relevant, since
the inserted characters are uppercased:

    compadd -M 'm:{a-zA-Z}={A-Za-z} r:|.=* r:|=*' "$@" $config_hosts

zsh 5.2-dev-1, 062aeca.


Thanks,
Daniel.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: SSH hostname completion with common suffix and globcomplete inserts characters

[Daniel Hahler]

[-- Attachment #1.1: Type: text/plain, Size: 1855 bytes --]

Another, seemingly related issue:

Given ssh_config2:

  Host foo-test-05827d88.foo.bar bar-test-6cae9ce0.foo.bar

% ssh -F ssh_config2 test<TAB>

completes to

% ssh -F ssh_config2 -test-|.foo.bar

and a second invocation of the completion will then use the "-t" at the
beginning (for "escape character (or `none')").

Should this get quoted on expansion to prevent this?


When quoting it manually, I see a similar issue as described before (see
below), where

  ssh -F ssh_config2 '-test-<TAB>.foo.bar'

gets expanded to

  ssh -F ssh_config2 '-test-BR.foo.bar'

(without the globcomplete option though!)


On 17.08.2016 21:16, Daniel Hahler wrote:
> When using TAB completion (via expand-or-complete, and "setopt
> globcomplete") on a partial hostname where alternatives with a common
> suffix exist, the second invocation of TAB will insert some character(s)
> that make it fail to complete afterwards.
> 
> 
> % autoload -Uz compinit
> % compinit
> % echo "Host test-05827d88.foo.bar test-6cae9ce0.foo.bar" > ssh_config
> % setopt globcomplete
> 
> With
> 
> % ssh -F ssh_config test-<TAB>
> 
> You will get:
> 
> % ssh -F ssh_config test-|.foo.bar
> 
> Pressing TAB again results in:
> 
> % ssh -F ssh_config test-|BR.foo.bar
> 
> The characters being inserted seem to come from the "bar".
> 
> With ".dot.com" at the end I am seeing "CM" being inserted.
> 
> With "Host test-05.dot.com test-6c.dot.com" however "D" is being
> inserted.
> 
> And with a single TLD (i.e. "test-05827d88.com test-6cae9ce0.com") it
> works.
> 
> In _ssh_hosts the following is used, which seems to be relevant, since
> the inserted characters are uppercased:
> 
>     compadd -M 'm:{a-zA-Z}={A-Za-z} r:|.=* r:|=*' "$@" $config_hosts
> 
> zsh 5.2-dev-1, 062aeca.
> 
> 
> Thanks,
> Daniel.
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: SSH hostname completion with common suffix and globcomplete inserts characters

[Bart Schaefer]

On Aug 17,  9:16pm, Daniel Hahler wrote:
}
} % echo "Host test-05827d88.foo.bar test-6cae9ce0.foo.bar" > ssh_config
} % setopt globcomplete
} % ssh -F ssh_config test-<TAB>
} % ssh -F ssh_config test-|.foo.bar
} % ssh -F ssh_config test-|BR.foo.bar

I compared _complete_debug output for the two cases and there's no
significant difference until the value of compstate[unambiguous] is
displayed near the end, so this looks like an off-by-one error in
the internals.

Cursory examination seems to point to implicit addition/removal of
the "*" pattern at the cursor position when doing globcomplete.  If
instead one explicitly completes

% ssh -F ssh_config test-*<TAB>

then a listing of possible matches appears and the update of the line
is correct.

} The characters being inserted seem to come from the "bar".

I think the characters being inserted are just stack (or heap) garbage;
it may coincidentally be garbage derived from trying a case replacement,
but I don't think that's directly related.

Places to look more closely seem to be computil.c:cfp_opt_pats() and
compcore.c:addmatches(), look for comppatmatch.  For example, most of
cfp_opt_pats() is skipped if the prefix or suffix already contains a
pattern (as in "test-*") but is active if the prefix has no pattern
and comppatmatch is non-empty (as is the case for globcomplete).

Re: SSH hostname completion with common suffix and globcomplete inserts characters

[Daniel Hahler]

[-- Attachment #1.1: Type: text/plain, Size: 2511 bytes --]

> % ssh -F ssh_config2 -test-|.foo.bar
> 
> and a second invocation of the completion will then use the "-t" at the
> beginning (for "escape character (or `none')").
> 
> Should this get quoted on expansion to prevent this?

This would need to be escaped using a backslash at the beginning:

  ssh -F ssh_config2 \-test-.foo.bar

> When quoting it manually, I see a similar issue as described before (see
> below), where
> 
>   ssh -F ssh_config2 '-test-<TAB>.foo.bar'
> 
> gets expanded to
> 
>   ssh -F ssh_config2 '-test-BR.foo.bar'
> 
> (without the globcomplete option though!)

The insertion of "BR" does not happen with "zsh -f" though.  It is
caused by matcher-list zstyle setting in my config: 'r:|[._-]=*'

My full setting (based on the one from oh-my-zsh):

  zstyle ':completion:*' matcher-list '' 'm:{[:lower:]}={[:upper:]}' \
    'm:{[:upper:]}={[:lower:]}' 'r:|[._-]=* r:|=*' 'l:|=* r:|=*'

While looking at it, it seems like 'r:|[._-]=* r:|=*' is redundant, but
the "COMPLETION MATCHING CONTROL" section in zshcompwid(1) is not really
trivial.

For some other reason I cannot reproduce the issue of "BR" being
inserted when using ssh_config2 with "zsh -f" just by using the same
matcher-list zstyle config.


> On 17.08.2016 21:16, Daniel Hahler wrote:
>> When using TAB completion (via expand-or-complete, and "setopt
>> globcomplete") on a partial hostname where alternatives with a common
>> suffix exist, the second invocation of TAB will insert some character(s)
>> that make it fail to complete afterwards.
>>
>>
>> % autoload -Uz compinit
>> % compinit
>> % echo "Host test-05827d88.foo.bar test-6cae9ce0.foo.bar" > ssh_config
>> % setopt globcomplete
>>
>> With
>>
>> % ssh -F ssh_config test-<TAB>
>>
>> You will get:
>>
>> % ssh -F ssh_config test-|.foo.bar
>>
>> Pressing TAB again results in:
>>
>> % ssh -F ssh_config test-|BR.foo.bar
>>
>> The characters being inserted seem to come from the "bar".
>>
>> With ".dot.com" at the end I am seeing "CM" being inserted.
>>
>> With "Host test-05.dot.com test-6c.dot.com" however "D" is being
>> inserted.
>>
>> And with a single TLD (i.e. "test-05827d88.com test-6cae9ce0.com") it
>> works.
>>
>> In _ssh_hosts the following is used, which seems to be relevant, since
>> the inserted characters are uppercased:
>>
>>     compadd -M 'm:{a-zA-Z}={A-Za-z} r:|.=* r:|=*' "$@" $config_hosts
>>
>> zsh 5.2-dev-1, 062aeca.
>>
>>
>> Thanks,
>> Daniel.
>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: SSH hostname completion with common suffix and globcomplete inserts characters

[Bart Schaefer]

On Aug 17,  9:38pm, Daniel Hahler wrote:
}
} Given ssh_config2:
} 
}   Host foo-test-05827d88.foo.bar bar-test-6cae9ce0.foo.bar
} 
} % ssh -F ssh_config2 test<TAB>
} 
} completes to
} 
} % ssh -F ssh_config2 -test-|.foo.bar

I can't reproduce this from "zsh -f" -- I had needed your matcher-list
style from your second message.

} and a second invocation of the completion will then use the "-t" at the
} beginning (for "escape character (or `none')").
} 
} Should this get quoted on expansion to prevent this?

It might be possible to fix this in this specific case, but in general
I don't think it can/should be handled.  This goes along with the usual
completion dilemma of whether to assume the user intends quoting to be
interpreted by completion to change the result, or to be kept in place
in order to affect the parse when the line is accepted.

A more ideal approach would be similar to using _oldlist, wherein the
internals would remember the previous semantic of the current word
(in this case, that it's an argument rather than an option) and use
that semantic again if another completion is attempted in the same
word position, rather than recalculating the context every time.

} When quoting it manually, I see a similar issue as described before (see
} below), where
} 
}   ssh -F ssh_config2 '-test-<TAB>.foo.bar'
} 
} gets expanded to
} 
}   ssh -F ssh_config2 '-test-BR.foo.bar'
} 
} (without the globcomplete option though!)

I'm not able to reproduce that, either, when quoted.  Instead I get a
listing of the two possible results, and then cycling through them
on repeated tabs.

On Aug 18, 12:52am, Daniel Hahler wrote:
}
} The insertion of "BR" does not happen with "zsh -f" though.  It is
} caused by matcher-list zstyle setting in my config: 'r:|[._-]=*'

There must be another zstyle in play somehow, because with this --

}   zstyle ':completion:*' matcher-list '' 'm:{[:lower:]}={[:upper:]}' \
}     'm:{[:upper:]}={[:lower:]}' 'r:|[._-]=* r:|=*' 'l:|=* r:|=*'

-- as my only zstyle, I can't reproduce the result above.  I *can*
reproduce the original report by adding globcomplete.

} While looking at it, it seems like 'r:|[._-]=* r:|=*' is redundant

The thing on the right side of the equal matches the trial completion,
whereas the thing on the left of the equal matches the command line.

So r:|=* means anything can match an empty word (nothing on the command
line) whereas r:|[._-]=* means anything can match after dot, underscore,
or hyphen.  The 'l:|=* r:|=*' may be redundant but I don't think the
other bits are.

} For some other reason I cannot reproduce the issue of "BR" being
} inserted when using ssh_config2 with "zsh -f" just by using the same
} matcher-list zstyle config.

As noted above, I get the "BR" thing only with globcomplete, and only
when the string on the line is not quoted.