* Re: [: Re: ssh scp completion] sorry wrong key pressed :/
2004-07-17 6:42 [: Re: ssh scp completion] sorry wrong key pressed :/ Martin Marcher
@ 2004-07-17 18:44 ` Bart Schaefer
0 siblings, 0 replies; 2+ messages in thread
From: Bart Schaefer @ 2004-07-17 18:44 UTC (permalink / raw)
To: zsh-users
On Sat, 17 Jul 2004, Martin Marcher wrote:
> On Fri, Jul 16, 2004 at 05:05:48PM +0200, Laurent Rineau wrote:
> > You can set up directly the style hosts:
> >
> > zstyle ':completion:*:*:*' hosts foo bar
> >
> > or use something like what I have in my .zshrc:
> >
> > [ -f ~/.ssh/config ] && : ${(A)ssh_config_hosts:=${${${${(@M)${(f)"$(<~/.ssh/config)"}:#Host *}#Host }:#*\**}:#*\?*}}
> > zstyle ':completion:*:*:*' hosts $ssh_config_hosts $ssh_known_hosts
>
> some explanation of this stuff would be more of what i thought, because
> from what i found out by now it's not only expansion there's a lot of
> stuff going on there.
It's hard to know what to explain ... a good place to start is probably to
run the "compinstall" function, create a few settings with it and save
them, then look at the results. (Hey, PWS -- it might be nice if there
were a way to tell compinstall "show me the result of the settings I just
made" so that it could be used as sort of an interactive tutorial. Even
if it could simply print to the screen the whole collection of styles
composed so far, that'd be a reasonable first step.)
The zstyle mechanism used for completion "context" can take a little
getting used to, but it's quite handy once you understand it.
In a variable reference, like $ssh_config_hosts, there's exactly one
name/value pair that can satisfy the lookup. A zstyle name, on the other
hand, includes a pattern, and so when a zstyle is looked up there may be
more than one name/value pair found. The clever bit is that zstyle makes
a judgement as to how "specific" the pattern is, and answers the lookup
with the name/value pair for the most specific pattern that matches.
The completion system makes use of this by building up an increasingly
detailed summary of its understanding of the command line. That summary
is the context, and is used as the lookup key against which the zstyle
patterns are matched to find the best fit. When you hit TAB, this summary
starts out essentially empty, so only a very nonspecific style pattern
will match it. As the various completion functions are called to analyze
the commenad and the current cursor position, they add to the context so
the more-specific zstyles will begin to match when settings are looked up.
So, depending on how early in the analysis a particular setting is needed,
it may not be useful to configure it differently for different commands or
situations. (The zstyle mechanism is generic and not tied to completion,
so it won't stop you from using any pattern you want, but some patterns
that might seem sensible are useless because the setting is never looked
up with a specific-enough context to be matched by the pattern.)
Having just wandered off on that tangent, perhaps I should have been
addressing this specific example. Laurent's style is a little unusual.
I would have written it this way:
[[ -f ~/.ssh/config && -z $ssh_config_hosts ]] && ssh_config_hosts=(...)
I'm not even certain that Laurent's example accomplishes what he meant,
because the stuff to the right in ${...:=...} is assigned as a string even
if you use the (A) flag; it's just that the name to the left is created as
a one-element array instead of as a scalar.
> and another question: why is it that i dont simply use some grep/awk
> combination?
Because it's frequently faster and less CPU-intensive to handle everything
inside zsh, rather than forking off a subshell, awk, grep, etc. and then
reading back the standard output of the pipeline. In this specific case
it only happens once, so it doesn't make as much difference, but for some
completions that sort of transformation is done every time you press TAB.
Most of the time these sorts of things get written first as a $(...) of a
complex shell pipeline and then, after the completion is working properly,
as much of the pipeline as possible is folded back into zsh parameter
expressions for efficiency. After you've done this several times, though,
it becomes possible to write the parameter expressions directly for the
more common sorts of transformations (in particular, "cut" is unnecessary
for someone really familiar with zsh parameter expansion, except when
processing very large files).
^ permalink raw reply [flat|nested] 2+ messages in thread