From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Marko Myllynen <myllynen@redhat.com>
Cc: zsh workers <zsh-workers@zsh.org>
Subject: Re: Zsh OpenStack completions
Date: Tue, 6 Sep 2016 23:37:51 +0000 [thread overview]
Message-ID: <20160906233751.GA17896@fujitsu.shahaf.local2> (raw)
In-Reply-To: <9361ff20-f0f2-9acd-e43e-4b1e2e203531@redhat.com>
Marko Myllynen wrote on Tue, Sep 06, 2016 at 15:39:02 +0300:
> Hi,
>
> Below is a patch to add completions for several OpenStack related
> command line clients, including the new common client, openstack(1).
>
> There are three categories of clients:
>
> 1) newer clients which provide per-command sub-commands and options
> 2) old skool clients which provide the "bash-completion" command
> 3) an oddball, swift, slightly different than 2)
It would be useful to have this information in a comment above the
declaration of the corresponding arrays.
More generally: having block-level comments would be useful. See for
example the computil.c part of 39173. Without them the code would be
harder to work on in the future.
> We cache things pretty aggressively as something like "neutron help"
> takes ~0.75s on my laptop (compared to 0.002 of "ls --help") and
> openstack(1) even goes over the network for the list of completions.
A brilliant example of the pendulum tendency to take us all back to the
dumb terminals era of the 70's :-)
> (Also, searching for (sub)commands from the associative
> array doesn't look very nice but I'm not sure how to do that better
> while still making sure that e.g. net-list and net-list-on-dhcp-agent
> are not being confused - perhaps I missed a flag to aid in this.)
I assume you refer to this line? —
for word in ${words:1}; do
[[ $_cache_openstack_clnt_cmds[$service] != ${${${_cache_openstack_clnt_cmds[$service]#$word }% $word}/ $word } ]] && cmd=$word && break
done
You could get around the triple % # / check by adding a space before and
after the string, i.e., let the associative array's value be
" foo bar baz "
and then just grep for " foo " (with the spaces).
Or you could use the (w) flag:
.
% s="foo foobar"
% print -r -- $s[(wI)foo]
1
% print -r -- $s[(wI)bar]
0
Or you could call use a different variable name for each command, i.e.,
«typeset -a _cache_openstack_magnum_subcommands» and so on. You'd then
use the (P) parameter expansion flag to access the variable:
.
cachevar=_cache_openstack_${service}_subcommands
typeset -a $cachevar
print -rl -- ${(P)cachevar}
compadd -a -- $cachevar
You may also need to change ${word} to ${(b)word} inside the condition
to prevent $word from being interpreted as a pattern. I know I said
that [offlist] above virsh too, I haven't made the change there yet but
I think I will later.
> There's one case which I'm not sure there's a perfect solution without
> hard-coding / special-casing lots of commands/options: some commands
> of some clients accept some options more than once - for example, for
> "openstack project create" the "--property" option could be repeated
> (to provide several key=value pairs).
I'm not sure what's the problem here: whether it's needing to write code
to permit select options to be specified multiple times or having to
enumerate all options that may be multiply-specified.
If it's the former: _arguments solves that for you:
.
_f() _arguments : '*-x:foo:_hosts'
compdef _f f
f -x bar -<TAB><TAB>
If it's the latter: the alternative to hardcoding a list would be to
parse that information from the --help or --completion output. This may
mean getting openstack upstream to emit that information therein.
(Tangentially: I wish there were a standard format for parseable help;
basically a variation of --help that emitted information that
(a) were machine parseable, (b) could be compiled into a zsh completion
function.)
> So if trying to stay generic,
> we'd need to accept several options in all cases (which is mostly
> incorrect) or accept options only once and force the user to type
> the option if wanted more than once. I've chosen the latter as
> it would seem that in most cases there's some typing needed anyway
> for repetitive options (like key=value pairs, DNS servers, IP
> addresses, etc), so while not perfect this doesn't strike me too
> cumbersome.
> ---
> Completion/Unix/Command/_openstack | 136 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 136 insertions(+)
> create mode 100644 Completion/Unix/Command/_openstack
I'll go through the diff later.
Cheers,
Daniel
next prev parent reply other threads:[~2016-09-06 23:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-06 12:39 Marko Myllynen
2016-09-06 23:23 ` Eric Cook
2016-09-07 7:12 ` Marko Myllynen
2016-09-06 23:37 ` Daniel Shahaf [this message]
2016-09-07 9:31 ` Marko Myllynen
2016-09-09 6:38 ` Marko Myllynen
2016-09-19 6:24 ` Marko Myllynen
2016-09-27 5:43 ` Marko Myllynen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160906233751.GA17896@fujitsu.shahaf.local2 \
--to=d.s@daniel.shahaf.name \
--cc=myllynen@redhat.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).